Symulator system design

Podejmuj decyzje architektoniczne krok po kroku i zobacz, jak zmieniają się kompromisy.

Krok 1 / 5

Scenariusz

Platforma typu Uber (ride-hailing)

Zaprojektuj architekturę dopasowywania przejazdów w czasie rzeczywistym, śledzenia i płatności.

Ograniczenia

•Szczyty ruchu w mieście rosną gwałtownie (godziny szczytu).
•Aktualizacje lokalizacji muszą być odczuwalne jako „real-time”.
•Ceny i płatności muszą być spójne i możliwe do audytu.

Wybierz strategię podziału usług.

Kontekst interviewera

Projektujemy backend platformy ride-hailing z real-time trackingiem i płatnościami przy skokach ruchu. Rozmówca chce zrozumieć, jak podzielisz usługi i własność danych na start.

Pytania interviewera

•Które domeny rozdzieliłbyś na początku (przejazdy, tracking, ceny, płatności) i dlaczego?
•Czy na start wybrałbyś modularny monolit czy mikroserwisy, biorąc pod uwagę zespół?
•Jak przypisałbyś własność baz danych do tych granic?

Pytania doprecyzowujące

Pokaż podpowiedzi dla rozmowy

•Ile zespołów będzie to budować/utrzymywać i czy potrzebujemy niezależnych wdrożeń?
•Jakie punkty bólu skalowalności lub dostępności trzeba od razu izolować?
•Czy mamy systemy legacy lub bazy danych, które muszą pozostać razem?

Wybierz podejście

Wskazówki

Pokaż wskazówki

Czego oczekuje rozmówca

•Opisz granice odpowiedzialności i blast radius.
•Uzasadnij wybór względem skali i struktury zespołów.

Założenia skali

•Doprecyzuj wielkość zespołu i tempo wdrożeń.
•Wskaż domeny, które zmieniają się najszybciej.

Co warto rozpisać

•Mapa usług z własnością danych.
•Granice wdrożeń i zależności.

Tryby awarii do omówienia

•Opóźnienia między usługami lub problemy z koordynacją.
•Wąskie gardła współdzielonej bazy danych.

Architektura

Click to zoom