Pytania rekrutacyjne z analizy decyzji z odpowiedziami

Przykładowe pytania

Kilka pytań z każdego poziomu z poprawną odpowiedzią i wyjaśnieniem.

Analiza decyzji · Junior

1. Strona renderowana na serwerze pozwala gościom wybrać ciemny motyw. Już pierwszy HTML musi mieć właściwy motyw, bez mignięcia. Gdzie trzymać wybór?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: W cookie czytanym przez serwer przy każdym żądaniu

   Tylko cookie dociera na serwer razem z żądaniem, więc HTML od razu renderuje się we właściwym motywie. localStorage pasuje do aplikacji czysto klienckich lub gdy mały skrypt inline może ustawić motyw przed malowaniem. Tabela w bazie pasuje do zalogowanych użytkowników, którzy chcą ustawienia na każdym urządzeniu, ale goście nie mają konta.

2. Pole wyszukiwania woła API płatne za każde żądanie. Wyniki mają pojawiać się w trakcie pisania, ale nie przy każdym klawiszu. Co pasuje?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Debounce: żądanie po krótkiej przerwie w pisaniu

   Debounce wysyła jedno żądanie po przerwie w pisaniu, więc seria klawiszy kosztuje jedno wywołanie, a wyniki pojawiają się bez dodatkowej akcji. Throttle pasuje do ciągłych strumieni, jak przewijanie czy zmiana rozmiaru, gdzie liczą się regularne aktualizacje, ale tu płaciłbyś za niedokończone słowa. Szukanie po Enter jest najtańsze i pasuje do drogich wyszukiwań, ale łamie wymaganie pokazywania wyników w trakcie pisania.

3. Artykuły popularnego bloga są edytowane kilka razy dziennie. Liczy się ruch z wyszukiwarek, a tekst sprzed godziny jest w porządku. Jak renderować strony?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Prerenderować je i odświeżać mniej więcej co godzinę

   Prerender z okresowym odświeżaniem daje czytelnikom i robotom szybki HTML z cache, a godzina nieaktualności jest tu dopuszczalna. Render przy każdym żądaniu pasuje do stron personalizowanych lub danych, które muszą być aktualne przy każdej wizycie, a tu tylko dodałby obciążenia. Render po stronie klienta pasuje do prywatnych paneli, ale opóźnia pierwsze malowanie i słabo pasuje do stron zależnych od wyszukiwarek.

4. Katalog sklepu internetowego ma 10 000 produktów. Klienci porównują je, udostępniają linki do pozycji i potrzebują stopki. Jak pokazać listę?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Numerowane strony z numerem w URL

   Numerowane strony dają każdej pozycji URL do udostępnienia i zostawiają stopkę w zasięgu, a tego właśnie wymaga katalog. Nieskończone przewijanie pasuje do feedów przeglądanych bez celu, gdzie pozycja nie ma znaczenia. Lista wirtualizowana pasuje do narzędzi z dużymi danymi, gdzie wszystkie wiersze są potrzebne na kliencie, ale pobieranie całego katalogu jest tu marnotrawstwem.

Analiza decyzji · Middle

1. Feed wiadomości obsługuje 1 mln użytkowników, może opóźniać się o minutę, a każde wywołanie zewnętrznego API jest płatne. Jakie jest główne podejście?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Wspólny cache serwera z TTL około 60 sekund

   Jeden wspólny wpis oznacza, że wszyscy użytkownicy kosztują jedno wywołanie na minutę, a minuta opóźnienia jest dopuszczalna. Cache w przeglądarce pasuje do danych osobistych i oszczędza powtórne wizyty, ale przy 1 mln użytkowników każdy i tak kosztuje wywołanie. Wywołanie przy każdej wizycie pasuje do danych, które muszą być dokładne, jak saldo, a tu tylko pomnożyłoby rachunek.

2. Po przelewie użytkownik otwiera saldo. Kwota musi być dokładna, a reszta aplikacji bankowej czyta z replik. Dokąd idzie ten odczyt?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Do primary, bez cache po drodze

   Pieniądze pokazane zaraz po zapisie muszą uwzględniać ten zapis, a gwarantuje to tylko primary. Replika pasuje do list i historii, gdzie sekunda opóźnienia jest nieszkodliwa. Cache z inwalidacją pasuje do danych często czytanych i rzadko zapisywanych, ale pominięta inwalidacja pokaże tu złe saldo, a to droższe niż dodatkowy odczyt.

3. Publikujesz API dla zewnętrznych partnerów piszących w wielu językach. Odpowiedzi mają działać z CDN, a pierwsze wywołanie partnera ma zająć minuty. Jaki styl?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: REST przez HTTP z opisem OpenAPI

   REST nie wymaga niczego poza klientem HTTP, a odpowiedzi GET od razu działają z CDN. GraphQL pasuje do klientów o bardzo różnych potrzebach danych, choć cache zwykle wymaga więcej pracy, bo zapytania często idą przez POST. gRPC pasuje do szybkich wewnętrznych wywołań między twoimi usługami, ale wymaga generowanych klientów i nie działa wprost z przeglądarki.

4. Aplikacje web i mobilna potrzebują bardzo różnych danych z tych samych usług. Każdy klient ma własny zespół, a mobilna cierpi przez duże odpowiedzi. Co dodać?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Osobny BFF w każdym zespole klienta

   BFF pozwala każdemu zespołowi kształtować odpowiedzi pod swoje ekrany i wydawać je bez czekania na innych. Parametr ?fields= pasuje do małych różnic w jednym zasobie, ale nie agreguje kilku usług dla ekranu. Bezpośrednie wywołania pasują do bardzo małego systemu, a tu dodadzą wymian sieciowych na mobile i ujawnią wewnętrzny układ usług.

Analiza decyzji · Senior

1. Serwis społecznościowy obsługuje głównie konta z kilkuset obserwującymi, a także konta z 50 mln. Odczyt ma być szybki. Jak budować feedy?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Hybryda: fan-out przy zapisie, oprócz ogromnych kont

   Wcześniej zbudowane feedy dają szybki odczyt większości kont, a dołączanie ogromnych kont przy odczycie unika milionów zapisów na post. Czysty fan-out przy zapisie pasuje do sieci bez skrajnych kont, ale jeden post gwiazdy zalałby ścieżkę zapisu. Czysty fan-out przy odczycie pasuje do systemów z małą liczbą odczytów i jest prosty, ale w tej skali składanie każdego feedu jest zbyt wolne.

2. Sklep serwuje strony produktów z globalnego CDN. Opisy zmieniają się rzadko, ale poprawiona cena musi pojawić się w kilka sekund. Jaka strategia cache?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Długi TTL w CDN plus czyszczenie po tagach przy zmianie

   Długi TTL utrzymuje wysoki odsetek trafień, a czyszczenie po tagu w kilka sekund wprowadza poprawioną cenę wszędzie. Krótki TTL pasuje do treści bez zdarzeń zmiany, ale kieruje na źródło znacznie więcej ruchu. Rezygnacja z CDN pasuje do w pełni personalizowanych stron, a tu odebrałaby szybkość odwiedzającym z całego świata.

3. Sześcioosobowy startup wciąż szuka dopasowania produktu do rynku, a granice domeny stale się przesuwają. Od jakiej architektury zacząć?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Modularny monolit z jasnymi granicami wewnętrznymi

   Modularny monolit utrzymuje tani refaktoring, gdy granice się przesuwają, a czyste moduły mogą później stać się usługami. Mikroserwisy pasują do wielu zespołów potrzebujących niezależnych wydań, a sześć osób traciłoby czas na sieć i wdrożenia. Funkcje na endpoint pasują do skokowych, izolowanych obciążeń, a rozrzucenie zmiennej domeny po nich utrudnia rozwój wspólnej logiki.

4. Po zapisaniu zamówienia usługa musi opublikować zdarzenie w brokerze. Zdarzeń nie wolno stracić, a broker nie uczestniczy w transakcji bazy. Co zrobić?
   ▸Pokaż odpowiedź

   Poprawna odpowiedź: Transactional outbox z publikacją przez relay

   Zapis zdarzenia w tej samej transakcji co zamówienie oznacza, że istnieją oba albo żadne, a relay dostarczy je później. Publikacja po commicie pasuje do zdarzeń, które można stracić, ale awaria między krokami je gubi. Publikacja najpierw nie pasuje do niczego, co ma być spójne, bo nieudany commit zostawia odbiorców reagujących na nieistniejące zamówienie.