System Design Interview: Jak zaprojektować Twittera? Wyjaśnienie

System-Design-Interview-Jak-zaprojektowac-Twittera

To jedno z najczęstszych pytań na rozmowach — rekruterzy chcą sprawdzić twoją zdolność do rozwiązywania złożonych problemów pod presją czasu.

W praktyce kandydaci często popełniają błąd: wymieniają technologie bez kontekstu i bez omówienia trade‑offów. Tutaj pokażemy, jak zbudować poprawną odpowiedź krok po kroku.

Ramę ułożymy tak, byś mógł płynnie przejść od doprecyzowania wymagań, przez estymacje skali, model danych i API, aż po architekturę oraz optymalizacje.

Podkreślimy narrację: najpierw cel produktu i ograniczenia, potem komponenty i technologie. Wskażemy kluczowe powierzchnie produktu — timeline, profil, search, notifications, media — i ich wpływ na architekturę.

Na końcu omówimy kompromisy: spójność vs latency, koszt vs wydajność, fan‑out vs złożoność, oraz zapowiemy kalkulacje RPS, throughput i storage dla multi‑regionowego, horyzontalnie skalowalnego systemu.

Kluczowe wnioski

• Rekruter ocenia proces myślenia, nie tylko listę technologii.
• Zacznij od celów produktu i ograniczeń, potem planuj komponenty.
• Skalowalność wymaga estymacji RPS i strategii storage.
• Wybory technologiczne muszą być uzasadnione trade‑offami.
• Najważniejsze powierzchnie (timeline, profil, search, notifications, media) kształtują architekturę.

Czytaj także: Jak zaprojektować design systems i biblioteki komponentów?

Dlaczego temat „design twitter” wraca na System Design Interview

Temat feedu regularnie pojawia się na rozmowach technicznych, bo łączy wiele krytycznych wyzwań architektonicznych. To świetny test: read‑heavy ścieżki, asynchroniczność, cache, ranking i spójność występują razem.

Pułapka to mechaniczne wyliczanie narzędzi bez kontekstu. Kandydat może wymienić rozwiązania, ale bez danych wejściowych i kryteriów sukcesu to tylko lista technologii.

Przed startem rozmowy warto doprecyzować wymagania. Zadaj o zakres MVP, SLA, które powierzchnie (home, profil, search) i non‑goals. To pokaże, że projektujesz pod requirements, nie pod modne komponenty.

Struktura i komunikacja

Stosuj RADIO: Requirements, Architecture, Data, Interface, Optimizations. Mów na głos swoje założenia. Proponuj alternatywy i uzasadniaj priorytety.

System Design Interview: Jak zaprojektować Twittera?

Zacznij od jasnego zakresu MVP: które funkcje dostarczają największą wartość przy najmniejszej złożoności. To pokazuje, że potrafisz priorytetyzować wymagania.

Core MVP: publikacja tweetów (tekst + media), follow, home timeline, profil, podstawowe interakcje (like/retweet/reply), search, notifications oraz trendy.

Non‑goals warto wypunktować wprost. Przykłady: Direct Messages, Audio Spaces, reklamy i zaawansowane rekomendacje ML — traktujemy je jako przyszłą pracę.

Mapowanie powierzchni na bounded contexts

Przypisz każdą powierzchnię do backendowych obszarów: tweet/engagement, graph, timeline, search, media, notifications, analytics.

Przygotuj odpowiedź na pytanie rekrutera: „co jest najtrudniejsze?” Wymień: materializacja timeline, strategia fan‑out, cache i celebrity problem — to pokazuje świadomość trade‑offów.

Wymagania funkcjonalne Twittera, które musisz umieć obronić

Wymagania opisujemy jako testowalne kontrakty. Dla każdej funkcji podajemy zachowanie, wejście/wyjście i kryteria akceptacji. To pozwala udowodnić, że projektujesz pod cele produktu, nie pod listę technologii.

Publikacja nowych tweetów: utworzenie rekordu tweet z tekstem, opcjonalnymi mediaRefs oraz ekstrakcją encji — hashtags, wzmianki, URL. Kryterium: new tweet musi być dostępny przez GET /tweets/{id} w czasie

Follow / Unfollow: operacje na grafie kierunkowym. Zapytania „kogo obserwuję” i „kto mnie obserwuje” muszą działać z paginacją i filtrem. Kryterium: spójność listy followerów po retry i idempotentnych operacjach.

Home i profile timeline: cursor‑based paginacja, stabilne sortowanie i sygnał „new tweets” bez zaburzania kolejności. Kryterium: paginacja powinna być deterministyczna i umożliwiać odczyt do N wpisów na stronę.

Engagement i wątki: like, retweet, reply i conversationId. Każde zdarzenie to append‑only zapis z idempotencją. Kryterium: licznik like/retweet odzwierciedla stan w w większości przypadków.

Wyszukiwanie: osobna powierzchnia z near‑real‑time indeksowaniem tweets, users i hashtags. Kryterium: nowe hashtagi powinny być widoczne w top results w określonym SLA.

Powiadomienia i trendy: notyfikacje dla wzmiank, like, follow i retweetów oraz cache top‑K hashtags per region. Kryterium: powiadomienie push lub inbox w near‑real‑time; trendy odświeżane co N sekund.

Wymagania niefunkcjonalne: dostępność, opóźnienia, spójność i koszt

Niefunkcjonalne cele determinują architekturę. Ustalamy konkretne SLA: read‑heavy p99 dla timeline/profili/search <300–500 ms, a p99 zapisu tweetów i operacji engagement <150–250 ms.

Durability oznacza: jeśli API zwróci sukces, tweet nie może zniknąć nawet przy awarii węzła lub regionu. W praktyce wymaga to replikacji i potwierdzeń zapisu.

Spójność projektujemy hybrydowo. Dopuszczamy eventual consistency dla timeline i liczników (opóźnienia rzędu kilku sekund). Wymagamy strong consistency dla handle/identity i mapowań użytkownik→handle.

Skalowanie obejmuje routing do najbliższego regionu i replikację danych. To poprawia latency, ale komplikuje spójność i koszt.

• Optymalizacja kosztów: CDN dla egress mediów, cache dla hot keys i tiered storage dla danych zimnych.
• Perspektywa koszt vs UX: lepszy cache i CDN często poprawiają perceived performance bardziej niż dodanie kolejnych baz.

Estymacje skali i obciążenia: RPS, throughput i piki ruchu

Proste, szybkie estymacje skali pozwalają uzasadnić decyzje o shardingu, cache i przetwarzaniu asynchronicznym.

Założenia: 1 mld user, 200 mln DAU, 5 tweets na dzień → 1 mld tweets/dzień.

Write path — szybkie liczby

1 mld tweetów/dzień ≈ 11 574 zapisów/s (~12k RPS dla tweet writes). Media to 10% → ~1 157 requests/s. Engagement (x3) daje ≈ 36k zapisów/s.

Read path — dominujący ruch

Home timeline ≈ 6 mld odczytów/dzień ≈ 69 444 requests/s (~70k RPS). Przy wydarzeniach na żywo load rośnie 5–10×.

Wnioski: read‑heavy wymusza cache per‑user i precomputing. Write‑heavy wymaga event logów, idempotencji i sharding.

Nierównomierny rozkład (celebryci, hot tweets) tworzy hotspoty, które trzeba obsłużyć przez rate limiting i hot‑key cache.

Estymacje storage i bandwidth: ile danych trzeba magazynować i przesłać

Klucz do kosztów leży w podziale na text i media. Tekst i metadane zajmują relatywnie mało miejsca, ale retencja na lata potrafi zmienić wymagania o rzędy wielkości.

Text: przy 1 mld wpisów/dzień × 100 B ≈ 100 GB/dzień. Przy retencji 10 lat to ~19 PB. To wpływa na wybór database, kompresję i polityki archiwizacji.

Media: 10% wpisów × 50 KB ≈ 5 TB/dzień. Media generują największy koszt egress, dlatego origin ingest musi współpracować z CDN dla egress i cache.

Indeks wyszukiwania to dodatkowy narzut. Inverted index może zwiększyć wymagania storage dla tekstu o 30–100% w zależności od tokenizacji.

Bandwidth: średnie obciążenie rzędu kilku TB/dzień kontra szczyty 5–10×. Plan capacity na servers i łącza musi uwzględniać piki, limit upload i throttling.

Generowanie identyfikatorów i tożsamość użytkownika

Generowanie identyfikatorów ma bezpośredni wpływ na wydajność timeline i spójność user data. Identyfikatory wpływają na sharding, paginację, sortowanie i debugowanie incydentów. Dlatego wybór formatu jest krytyczny dla skalowalności.

Snowflake: 64‑bitowy, oparty na czasie identyfikator

Snowflake łączy znaczniki time, worker/node i sekwencję w 64‑bitowy id. Taki format daje rosnące, unikalne wartości. To ułatwia cursor‑based pagination i szybkie sortowanie append‑only strumieni.

Gdzie stosować Snowflake

Używaj Snowflake dla tweetId, notificationId i timeline entryId. Wszystkie te elementy są append‑only, więc rosnące ids redukują koszt paginacji i konsolidacji wyników.

Przydział workerId i typowe ryzyka

Przydziel workerId per region/cluster, kontroluj przydziały przez centralny serwis. Należy obsłużyć:

• cofnięcie zegara (clock regression) — fallback do monotonicznego licznika;
• wyczerpanie sekwencji w jednej milisekundzie — backoff lub rezerwacja dodatkowych bitów.

Handle vs userId

UserId powinno być kanoniczne i niemutowalne. Handle to alias, który może się zmieniać. Trzymaj silne mapowanie handle → userId z gwarancją konsystencji, aby uniknąć konfliktów i przejęć nazw.

Model danych: kluczowe encje i relacje w systemie

Model danych to punkt startowy dla shardingu, indeksów i przetwarzania zdarzeń. Jasne zdefiniowanie encji ułatwia wybór, gdzie denormalizować, a gdzie trzymać canonical store.

Users i user data

Tabela Users zawiera podstawowe pola profilu, statusFlags i ustawienia prywatności. Denormalizowane liczniki (followersCount, followingCount, tweetsCount) skracają ścieżkę odczytu dla profili.

Tweets

Encja Tweets przechowuje treść, extracted entities (hashtag/mention/url), mediaRefs, conversationId i visibility. Liczniki (likes/retweets/replies) mogą być utrzymywane osobno dla wydajności.

Followers (graf)

Graf to krawędzie kierunkowe (follower → followee). Potrzebujemy widoków wtórnych: followersOf i followingOf, by obsłużyć fan‑out podczas publikacji i zapytań o społeczny kontekst.

Engagements

Like i retweet zapisujemy jako append‑only events. To ułatwia audyt, umożliwia idempotencję oraz strumieniowe przetwarzanie do aktualizacji liczników.

Feeds / TimelineEntry

TimelineEntry to materializacja N:M między users a tweets. Każdy wpis zawiera cursor, rankHint i timestamp. Dopuszczalna eventual consistency sprzyja denormalizacji i szybkiej obsłudze timelines.

API i kontrakty: jak projektować requests pod timeline, tweet i search

API musi być przewidywalne i skalowalne. Kontrakty definiują, co klient może oczekiwać przy szczytach ruchu i co serwer gwarantuje w kwestii trwałości.

POST /tweets — walidacja treści, przyjęcie mediaRefs i zapis metadanych. Serwis zwraca szybkie ack po zapewnieniu trwałości (quorum write), a dalszy fan‑out odbywa się asynchronicznie.

GET /timeline/home — używaj cursor‑based pagination zamiast offsetów. Cursor oparty na ID/czasie daje stabilne sortowanie i deterministyczne ładowanie kolejnych page. „New tweets” oznaczamy badge’em i uzupełniamy feed w tle.

GET /tweets/{id} — zwraca tweet + conversationId. Pobieranie odpowiedzi można robić jako paginowane drzewo lub spłaszczony łańcuch, w zależności od granularity UI.

POST /tweets/{id}/like i /retweet — wymagaj idempotency key, waliduj limity per user oraz stosuj rate limiting. Liczniki aktualizuj asynchronicznie, z mechanizmem korekcji.

GET /search — expose params: type, sort, lang, geo oraz filtrowanie dla bloków i mutów po stronie serwera. Zapytania muszą uwzględniać cache wyników i ograniczenia związków z performance.

„Kontrakty API to fundament skalowalnego feedu — proste requests, silne gwarancje.”

Architektura wysokopoziomowa: mikroserwisy i podział odpowiedzialności

Najpierw przypisz wymagania do jasno wydzielonych komponentów. To zapobiega sprzężeniom i ułatwia skalowanie przy rosnącym load.

Warstwa wejścia powinna zawierać API Gateway, mechanizmy auth oraz rate limiter. Te elementy chronią przed nadużyciami i stabilizują latency przy spike’ach.

Tweet i Engagement

Oddzielny Tweet service obsługuje write path dla nowych wpisów i reply. Engagement service przyjmuje like, retweet i aktualizuje licznik asynchronicznie. Taki podział pozwala skalować zapisy niezależnie od odczytów.

Graf społeczny i timeline

Social Graph service trzyma follow edges i odpowiada na pytania „kogo obserwuję”.

Timeline service jest read‑heavy: materializacja, per‑user cache i mechanizmy invalidacji minimalizują opóźnienia przy dużym ruchu.

Search, Media i powiadomienia

Search service odpowiada za indeksowanie i ranking zapytań. Media service zajmuje się uploadem, metadanymi i integracją z CDN. Notification service realizuje inbox i push fanout.

Event bus

Event bus pełni rolę logu zdarzeń. Pozwala na asynchronicznych konsumentów do fanout, indeksowania i metryk. Dzięki temu serwisy pozostają luźno powiązane.

„Mapuj wymagania na komponenty zanim wybierzesz narzędzia — event bus daje elastyczny kręgosłup asynchroniczny.”

Ścieżka zapisu nowego tweeta: od klienta do trwałego zapisu

Ścieżka zapisu nowego tweeta zaczyna się po stronie klienta i kończy na trwałym zapisie w rozproszonym store. Opisujemy tu kolejne kroki, tak by spełnić SLA p99 < 150–250 ms i gwarantować durability — brak utraty zaakceptowanych wpisów.

Walidacja, autoryzacja i rate limiting

Klient wysyła requests do API Gateway. Gateway sprawdza token, limity i politykę treści.

Walidacja obejmuje długość tekstu, mediaRefs i polityki bezpieczeństwa. Autoryzacja upewnia się, że użytkownik może publikować.

Rate limiting chroni UX i stabilność systems, odrzucając nadmiarowe requests zanim trafią do serwisu zapisu.

Zapis do store i log zdarzeń

Tweet trafia do Tweet service, gdzie generujemy unikalne ids (np. Snowflake) przed trwałym zapisem.

Zapis odbywa się z potwierdzeniem quorum/replication. Po potwierdzeniu serwis zwraca szybkie ack — spełnia to wymóg „no lost acknowledged tweets”.

Eventy TweetCreated i konsumenci

Po trwałym zapisie emitujemy zdarzenie TweetCreated do event busa. Konsumenci działają asynchronicznie:

• timeline fanout — materializacja feedów;
• search indexing — aktualizacja indeksu;
• analytics/metrics — agregacja i metryki performance;
• notifications — pushy i inboxy.

Asynchroniczność skraca p99 zapisu, ale wprowadza eventual consistency w powierzchniach odczytowych.

„Potwierdzenie trwałości przy zapisie i emisja TweetCreated to podstawy odpornego i skalowalnego write path.”

Projektowanie timeline: fan-out on write vs fan-out on read vs hybryda

Decyzja o modelu dystrybucji feedu wpływa na koszty, latency i odporność na piki. Trzy podejścia mają różne kompromisy dla performance i operacji przy celebrytach.

Pull (fan‑out on read) upraszcza ścieżkę zapisu. Przy żądaniu pobieramy listę followee, łączymy ich ostatnie wpisy i rankujemy. To obniża write cost, ale podnosi read latency i obciążenie serwerów merge/rank.

Push (fan‑out on write) materializuje feed przy publikacji. Odczyt jest szybki, co poprawia perceived performance, lecz write path i storage rosną znacząco. Problem celebrytów (miliony followers) wymaga throttlingu i specjalnych kolejek.

Hybryda kombinuje oba podejścia. Przyjmujemy próg followersCount: użytkownicy poniżej progu są push‑owani, a konta masowe obsługujemy pull‑owo. Do tego stosujemy per‑user caching stron feedu i krótkie TTL, by zmniejszyć load podczas spike’ów.

Ranking MVP

Wersja bez ML: recency jako podstawa, plus weighting za engagement (likes i retweets), affinity i diversity. Taki heurystyczny miks daje sensowny feed i łatwy do wdrożenia prototyp.

„Hybryda z progiem followersCount i per‑user cache to praktyczne rozwiązanie dla read‑heavy produktów.”

Cache i wydajność: jak dowieźć p99 dla timeline i profili

Cache jest głównym narzędziem do osiągnięcia p99 <300–500 ms dla home timeline i stron profilu. Przy read‑heavy obciążeniu wielowarstwowe podejście redukuje liczbę zapytań do głównych store i poprawia perceived performance.

Per‑user cache stron timeline

Materializujemy strony feedu per user i trzymamy je w szybkim cache z krótkim TTL. Przy odświeżaniu stosujemy background refresh, by uniknąć blokowania requestów.

Invalidacja następuje przy „new tweet” dla obserwujących. Aby zapobiec stampede, używamy request coalescing i jitter‑owanych TTL.

Hot tweet bodies i aktualizacje liczników

Treść popularnych wpisów trzymamy w cache keyed by tweetId. Timeline przechowuje lekkie referencje; pełne body fetchuje się z cache. To skraca page render.

Liczniki (likes/retweets/replies) obsługujemy jako write‑through dla mało obciążonych kluczy i write‑back z batchem dla gorących counterów. Dodatkowo stosujemy sharded counters i ergonomię rate limiting.

CDN i cache‑control dla media

Media serwujemy przez CDN z wersjonowanymi URL‑ami. Origin ingest jest oddzielony od egress; polityki cache‑control i lifecycle zmniejszają koszt transferu.

Monitoring hit ratio i latencji w multi‑region jest krytyczny. Metryki wskazują hot keys i pozwalają dobrać TTL oraz strategię replikacji.

„Cache per‑user plus hot‑key caching i CDN to praktyczne trio dla stabilnego p99 w produktach read‑heavy.”

Wyszukiwanie i indeksowanie: Elasticsearch/Lucene w praktyce

Search działa jako osobny service, bo ma inne wzorce odczytu, wymagania SLA i potrzeby skalowania niż główny tweet store.

Indeks odwrócony, tokenizacja i encje

Indeks odwrócony dzieli tekst na tokeny i przechowuje mapping token → dokumenty. Należy wykrywać entities: hashtags, mentions i URL.

Segmenty realtime służą do szybkiego indeksowania nowych tweets, a archive trzyma starsze dane z wyższą kompresją.

Przepływ indeksowania i zapytania

TweetCreated trafia do pipeline: parser → enrich (entities, language) → dokument w indeksie. Pole dokumentu zawiera pola do filtrowania i rankingu.

Zapytania przechodzą parsing i query‑rewrite (synonimy, normalizacja hashtagów). Ranking domyślnie używa BM25; ML może dodać rerank przy krytycznych wynikach.

Filtry bezpieczeństwa i personalizacja

Wyniki muszą uwzględniać blokady, muty, preferencje językowe i geo. Widoczność i usunięcia propagują się asynchronicznie — stąd eventual consistency między store a indeksem.

Dobry search łączy szybkość indeksowania z poprawnymi filtrami polityk i personalizacją.

Trendy i analityka: jak wykrywać top hashtagi oraz mierzyć system

Trend definiujemy tu jako top hashtagi lub tematy w danym regionie w ostatnich minutach lub godzinach, z wagą świeżości. Cel MVP to prosty, deterministyczny ranking, który można serwować nisko‑latencyjnie.

Rolling counters i okna czasowe z decay

Stosujemy sliding windowy i rolling counters, by mierzyć aktywność w kilku oknach (np. 1m, 10m, 60m). Każde zdarzenie przyczynia się z wagą zależną od wieku — decay wypiera stare sygnały bez ręcznego resetu.

Proste agregaty (hash → count) można przechowywać w pamięci z okresowym flushowaniem do trwałego store’u.

Cache top‑K per region i aktualizacja cykliczna

Wyniki top‑K buforujemy per region w szybkim cache. To artefakt gotowy do serwowania przez API z niską latencją i przewidywalnym kosztem.

Harmonogram aktualizacji ustalamy jako co N sekund dla szybkiej świeżości i co M sekund dla pełnej recompute. To kompromis między freshness a dodatkowym load.

Stream processing vs batch

Streaming (np. Kafka + stream processors) buduje near‑real‑time trendy i alerty. Batch (np. nocne joby) daje raporty i historyczne data dla modeli.

Pipeliney dostarczają także feature’y do rankingu: velocity, burstiness i user affinity. Te feature’y zasilają ranking w czasie prawie rzeczywistym.

„Definicja trendu i harmonogram aktualizacji decydują o kosztach i użyteczności metryk.”

• Kluczowe metryki: p99 pipeline latency, error rate, throughput i time‑to‑visibility dla nowych hashtagów.
• Monitoruj też load na stream processorach i hit ratio cache, aby dobrać N/M i TTL.
• Feature’y do rankingu powinny uwzględniać świeżość time, velocity i regionalną dystrybucję.

Media pipeline oraz powiadomienia: niezależne systemy o dużej skali

Media i notification traktujemy jako osobne subsystemy. Mają inne profile obciążenia i wymagają dedykowanych usług, które nie przeciążą głównego tweet store.

Upload, skanowanie i transkodowanie

Klient otrzymuje signed URL do bezpośredniego uploadu. To odciąża API i zmniejsza peak load.

Po ingest następuje skan bezpieczeństwa i asynchroniczne transkodowanie do wariantów (miniatury, web‑friendly). Dzięki temu front pobiera przygotowane pliki, co poprawia perceived performance.

Przechowywanie obiektów i lifecycle

Pliki trafiają do object storage z tiered policy: gorący tier dla ostatnich dni, zimny dla archiwum. To ogranicza koszty przy dużym wolumenie (np. ~100M plików/dzień przy 10% wpisów).

CDN i egress

CDN przejmuje większość egress, stabilizuje p99 i zmniejsza koszt origin. Wersjonowane URL zapobiegają stale cache.

Powiadomienia: kolejki, reguły, push

Notification service używa kolejek do fanout i agregacji zdarzeń. Reguły preferencji decydują, czy wysłać push przez FCM/APNS czy zapisać do inboxa w aplikacji.

Inbox jest źródłem prawdy — push to dodatkowa warstwa. Taka architektura zwiększa odporność na błędy dostarczania.

„Oddzielne pipelines dla mediów i powiadomień upraszczają skalowanie i optymalizację kosztów.”

Frontend timeline jako „system”: RADIO, renderowanie i optymalizacje klienta

Klient timeline nie jest jedynie warstwą prezentacji; to aktywny konsument i organizator danych. W praktyce frontend pełni rolę rozproszonego komponentu, który odpowiada za fetch, cache, konsystencję i responsywność strony.

RADIO — Requirements, Architecture, Data model, Interface, Optimizations

Requirements: szybkie ładowanie strony, płynny scroll, sygnalizacja „new tweets” i spójne optimistic updates.

Architecture: klient zawiera warstwy View, Store i Data access. Store normalizuje encje i trzyma cache per‑user.

Data model: lekki snapshot feedu (ids + rankHint), oddzielone body tweetów i mediaRefs, by ograniczyć payloady.

Interface: proste API kontrakty: paginacja kursorem, prefetch i metadane do renderu.

Optimizations: virtualizacja listy, lazy loading mediów, skeleton UI i prefetch kolejnej strony dla płynnego UX.

SSR vs CSR vs hybryda — trade‑offy dla personalizowanej osi czasu

SSR poprawia time‑to‑first‑byte i SEO dla publicznych stron, ale przy personalizacji koszt hydracji rośnie.

CSR daje bogatsze interakcje i prostszą logikę cache, lecz wydłuża TTFP. Hybryda (server‑render + client hydrate + incremental fetch) łączy zalety obu podejść.

SPA i warstwy klienta

View: lekkie komponenty, wirtualizacja listy, placeholdery. Store: globalny, normalizacja danych, per‑user cache. Data access: klient API z retry, backoff i staleness policy.

Optymalizacje UX / performance

Wirtualizacja renderuje tylko widoczne elementy, co zmniejsza koszty rysowania strony.

Lazy loading mediów i prefetch kolejnej strony zmniejszają zużycie pasma i przyspieszają odczuwalną szybkość.

Optimistic updates dla like/retweet przyspieszają reakcję klienta. Po otrzymaniu korekty z serwera wykonaj reconcile i korektę stanu.

„Klient staje się pełnoprawnym elementem architektury: jego optymalizacje decydują o perceived performance i spójności.”

Wniosek

Podsumowanie scala wymagania, estymacje i architekturę w praktyczny plan obronny. Wykaż, że rozumiesz trade‑offy: koszt vs wydajność, spójność vs świeżość i prostotę vs skalowalność.

Skoncentruj się na kluczowych wyborach: model danych dla users i tweets, strategia timeline (push/pull/hybryda) oraz jasne kontrakty API. Celuj w p99 read ≈ 300–500 ms, p99 write ≈ 150–250 ms i durability bez utraty zaakceptowanych treści.

Użyj liczb do obrony decyzji (np. 1 mld tweets/dzień i 5–10× piki odczytu), pokaż wpływ cache i CDN na latency i storage. Zakończ checklistą do powtórki: wymagania, SLA, ids, timeline, cache, search, media pipeline i monitoring.