Framework w pięciu fazach (tempo na 45 minut)
- Wymagania: 5 minut. Oddziel wymagania funkcjonalne („skracanie adresu URL, przekierowanie, własne aliasy?”) od niefunkcjonalnych (skala, docelowe opóźnienia, dostępność czy spójność, trwałość danych). Poproś o liczby: użytkownicy, proporcja odczytów do zapisów, rozmiar danych. Potem powiedz na głos, jaki zakres przyjmujesz: „Projektuję dla 100 mln DAU, z przewagą odczytów 100:1 i przekierowaniami poniżej 100 ms, a analitykę pomijam, chyba że zostanie czas”. Określenie zakresu na głos to ruch, który w tej rozmowie daje najmocniejszy sygnał.
- Szacowanie: 5 minut. Szybkie rachunki na kolanie: QPS, przestrzeń dyskowa, przepustowość. Zaokrąglaj do potęg dziesiątki, podawaj założenia i sprawdzaj, czy wynik ma sens („500 mln nowych adresów URL miesięcznie ≈ 200 zapisów/s, czyli skromnie; odczyty przy 100:1 ≈ 20 tys./s i to one kształtują projekt”). Nie chodzi o precyzję, tylko o pokazanie, że twoje wybory architektoniczne wynikają z liczb.
- Projekt wysokopoziomowy: 10 minut. Prostokąty i strzałki dla ścieżki podstawowej (happy path): klienci, load balancer, bezstanowa warstwa aplikacji, magazyny danych, cache, kolejka. Przeprowadź na głos jedno żądanie od początku do końca. Niech będzie nudno: nowinki to tutaj ryzyko bez nagrody.
- Pogłębienia: 20 minut. Rekruter wybiera komponent („jak dokładnie generowanie identyfikatorów unika kolizji?”, „co się dzieje, gdy pada węzeł cache’a?”). To tutaj rozdzielają się poziomy stanowisk. Mów konkretami: model danych, wybór klucza partycjonowania, scenariusze awarii, co budzi on-calla o trzeciej nad ranem.
- Podsumowanie: 5 minut. Wąskie gardła, którymi warto zająć się w następnej kolejności, co należy monitorować i co celowo zostało pominięte. Zakończenie listą znanych ograniczeń świadczy o senioralności, a nie o słabości.
Słownictwo kompromisów, po którym poznaje się seniora
Rekruterzy nasłuchują, czy bez podpowiedzi sięgasz po te wymiary:
| Wymiar | Zdanie, które punktuje |
|---|---|
| Spójność a dostępność | „Przy liczniku obserwujących zaakceptuję nieaktualne dane, przy rejestrze płatności już nie: różne magazyny danych dla różnych gwarancji”. |
| Opóźnienie a koszt | „Cache dla 1% najpopularniejszych kluczy obsłuży ok. 90% odczytów, a cache’owanie wszystkiego potraja zużycie pamięci przy znikomym wzroście hit rate”. |
| Push a pull | „Fan-out przy zapisie dla zwykłych użytkowników, fan-out przy odczycie dla kont celebrytów, czyli hybryda zależna od liczby obserwujących”. |
| SQL a NoSQL | „Wzorzec dostępu to klucz-wartość po krótkim kodzie, bez joinów, i to on, a nie moda, uzasadnia tutaj bazę szerokokolumnową”. |
| Synchronicznie a asynchronicznie | „Użytkownik musi dostać potwierdzenie zapisu, a rozsyłanie powiadomień może pójść przez kolejkę i dotrzeć z opóźnieniem”. |
Metazasada: nigdy nie wymieniaj technologii bez wskazania właściwości, dzięki której zasługuje na miejsce w projekcie. „Kafka” to słowo, a „partycjonowany log, żeby konsumenci mogli odtworzyć zdarzenia po awarii” to powód.
Dziesięć najczęstszych zadań system design i sedno każdego z nich
- Skracacz linków. Sedno: generowanie identyfikatorów (licznik + base62 albo hash + obsługa kolizji) i cache na ścieżce odczytu. Klasyczna rozgrzewka: spodziewaj się pytań uzupełniających o analitykę i wygasanie linków.
- System czatu (WhatsApp/Slack). Sedno: zarządzanie połączeniami (WebSockets, status obecności), kolejność wiadomości w ramach rozmowy, gwarancje i potwierdzenia doręczenia, synchronizacja offline.
- Feed (Twitter/Instagram). Sedno: strategia fan-outu i problem celebrytów, ranking jako osobny serwis, paginacja kursorami, a nie offsetami.
- Rate limiter. Sedno: wybór algorytmu (token bucket czy sliding window), rozproszone zliczanie (Redis + Lua), fail-open czy fail-closed oraz miejsce w architekturze (gateway czy każdy serwis osobno).
- Przechowywanie plików (Dropbox/Drive). Sedno: dzielenie na fragmenty (chunking) i deduplikacja, protokół synchronizacji i rozwiązywanie konfliktów, rozdzielenie metadanych od blobów.
- Platforma wideo (YouTube). Sedno: pipeline przesyłania plików (transkodowanie jako zadania asynchroniczne), strategia CDN, adaptacyjny bitrate, ekonomia przechowywania danych.
- Dopasowywanie przejazdów (Uber). Sedno: indeksowanie geoprzestrzenne (geohash/quadtree), wolumen zapisów z aktualizacji lokalizacji, dopasowywanie jako serwis stanowy, ceny dynamiczne (surge) jako strumień danych cenowych.
- System powiadomień. Sedno: abstrakcja wielu kanałów (push/e-mail/SMS), preferencje i limity częstotliwości dla każdego użytkownika, idempotentność i ponawianie z deduplikacją, kolejki priorytetowe.
- Rozproszony cache. Sedno: consistent hashing, polityka usuwania wpisów (eviction), cache-aside czy write-through, ochrona przed efektem thundering herd (łączenie żądań, TTL z losowym rozrzutem).
- System metryk i monitoringu. Sedno: wolumen zapisów szeregów czasowych, downsampling i poziomy retencji, eksplozja kardynalności tagów, ewaluacja alertów jako przetwarzanie strumieniowe.
Przećwicz co najmniej trzy zadania od początku do końca, na głos, na tablicy albo w dokumencie, w tempie na 45 minut. Opowiadanie o projekcie i rozpisywanie go to dwie różne umiejętności, a rozmowa ocenia opowiadanie. Próbna rozmowa z asystentem AI do rozmów kwalifikacyjnych daje feedback na poziomie transkrypcji: zobaczysz dokładnie, w którym miejscu twoje wyjaśnienie zgubiło wątek. ChadFlow może też podczas rozmowy na żywo obserwować okno z twoim diagramem i pomóc, gdy padnie pytanie uzupełniające.
Pięć sposobów, na jakie kandydaci oblewają ten etap
- Pomijanie wymagań. Pięknie zaprojektowany niewłaściwy system to najczęstsza porażka. Zapobiega jej trzydzieści sekund ustalania zakresu.
- Szacowanie na pokaz. Rachunki, z których potem nic nie wynika. Jeśli twój szacunek QPS nie zmienia projektu, to był tylko występ.
- Architektura z buzzwordów. Rzucanie hasłami Kafka, Cassandra czy Kubernetes bez opisanego wyżej uzasadnienia opartego na właściwościach.
- Monolog. Ten etap sprawdza współpracę. Dopytuj: „mam wejść głębiej w warstwę przechowywania danych czy przejść do API?”
- Brak scenariusza awarii. Przy każdym komponencie, który rysujesz, powinna istnieć odpowiedź na pytanie „co się stanie, gdy to padnie?”. Przygotuj ją, zanim narysujesz prostokąt.
Opowiadaj o projektach tak, jakby to nie był twój pierwszy raz.
ChadFlow transkrybuje twoje próbne rozmowy z projektowania systemów, między sesjami pomaga dopracować wyjaśnienia, a na żywo wspiera cię, widząc tylko wybrane okno z diagramem. Pozostaje przy tym niewidoczny przy udostępnianiu ekranu.
Pobierz ChadFlow