Architektura komórkowa dzieli usługę na niezależne instancje nazywane komórkami, z których każda jest w stanie autonomicznie obsługiwać część ruchu. Dla platformy płatności każda komórka składa się z pełnego stosu: load balancerów, serwerów aplikacyjnych, baz danych i kolejek wiadomości, wdrożonych w wielu strefach dostępności, ale izolowanych od innych komórek na poziomie sieciowym i danych. Routing ruchu oparty jest na deterministycznym szardingowaniu z wykorzystaniem identyfikatorów klientów, co zapewnia, że pojedynczy klient jest przypisany wyłącznie do jednej aktywnej komórki, a jednocześnie utrzymuje możliwość opróżniania i rotacji komórek bez zakłócenia usługi.
Spójność między komórkami w przypadku przekrojowych problemów (np. wykrywanie oszustw, raportowanie zgodności) jest osiągana dzięki asynchronicznej replikacji zdarzeń z wykorzystaniem strumieni Change Data Capture (CDC), podczas gdy transakcje wewnątrz komórek utrzymują gwarancje ACID za pośrednictwem lokalnych klastrów baz danych. Rotacja komórek wykorzystuje wzorce blue-green deployment w granicach komórki, połączone z wyłącznikami obwodu i ukierunkowaniem ruchu na podstawie monitorowania stanu na globalnym poziomie Edge CDN, aby automatycznie izolować degradujące się komórki.
Przetwórca płatności poziomu pierwszego obsługujący transakcje o wartości 15 miliardów dolarów dziennie doświadczył katastrofalnej awarii kaskadowej w swojej regionalnej monolicie US-East, gdy zepsucie indeksu bazy danych rozprzestrzeniło się na różne strefy dostępności. Skutkiem tego była globalna przerwa w działaniu trwająca 4 godziny, która dotknęła 40 milionów klientów i naruszyła wymagania dotyczące dostępności PCI DSS. Analiza po zdarzeniu ujawniła, że współdzielone komponenty infrastruktury stworzyły ukryte zależności awarii, naruszając zasadę niezależnych domen awarii wymaganą do wysokiej dostępności w systemach finansowych.
Rozwiązanie A: Aktywna-aktywna replikacja międzyregionowa
To podejście wdrożyłoby identyczne staki w wielu regionach z wykorzystaniem replikacji baz danych multi-master z użyciem Galera Cluster lub CockroachDB, co pozwoliłoby na zapisy w każdym regionie. Główną zaletą jest pełne wykorzystanie zasobów i lokalność geograficzna w celu redukcji opóźnień. Jednak złożoność rozwiązywania konfliktów przy transakcjach finansowych wprowadza nieakceptowalne ryzyko podwójnego wydania lub niespójnych stanów salda w trakcie podziałów sieciowych, podczas gdy obciążenie operacyjne związane z zarządzaniem vector clocks i merge conflicts rośnie wykładniczo wraz z wolumenem transakcji.
Rozwiązanie B: Aktywne-pasywne z gorącym zapasowym
Wdrażając architekturę gorącego zapasowego, utrzymuje się wtórny region w stałej synchronizacji za pomocą synchronizowanej replikacji, gotowy do przejęcia ruchu w ciągu kilku sekund po awarii podstawowej. To zapewnia silną spójność i eliminuje scenariusze split-brain poprzez wyraźną orkiestrację przełączania awaryjnego. Krytyczną wadą jest 50% marnotrawstwa zasobów podczas normalnych operacji oraz niemożność przeprowadzania stopniowych rotacji lub aktualizacji bez pełnych zdarzeń przełączenia, co komplikuje rutynowe okna konserwacyjne i zwiększa ryzyko wdrożenia.
Rozwiązanie C: Częściowe rozdzielanie oparte na komórkach z deterministycznym routingiem
Wybrana architektura dzieli bazę klientów na 20 wyraźnych komórek, z których każda obsługuje 5% globalnego ruchu z izolowanymi klastrami Kubernetes, dedykowanymi bazami primarnymi PostgreSQL i niezależnymi brokerami Kafka. Boczne kontenery Envoy Proxy wdrażają spójne haszowanie na customer_id, aby skierować żądania do określonych komórek, podczas gdy globalny kontroler monitoruje stan komórek i orkiestruje odprowadzanie ruchu podczas rotacji. To ogranicza strefę wpływu do 5% użytkowników podczas awarii na poziomie komórki i umożliwia rotacje bez przestojów poprzez stopniowe przenoszenie ruchu do nowych pokoleń komórek z wykorzystaniem analizy canary i automatycznych wyzwalaczy wycofywania.
Po wdrożeniu platforma osiągnęła 99,999% dostępności (mniej niż 5 minut przestoju rocznie), zmniejszyła strefę wpływu incydentu o 95%, a także zmniejszyła ryzyko wdrożenia dzięki wdrożeniom canary na poziomie komórek, które weryfikowały zmiany na podstawie podzbiorów ruchu produkcyjnego przed globalnym wdrożeniem.
Jak utrzymujesz integralność referencyjną dla encji, które rozciągają się na wiele komórek, takich jak konta korporacyjne z subkontami rozdzielonymi na różne komórki?
Kandydaci często błędnie zakładają, że ścisła izolacja komórek uniemożliwia jakiekolwiek transakcje międzykomórkowe. Rozwiązanie wdraża wzorzec Saga z kompensacyjnymi transakcjami orkiestrującymi przez lekkiego silnika Temporal lub Camunda działającego w oddzielnej płaszczyźnie kontrolnej. Do operacji międzykomórkowymi system wykorzystuje dwuetapowy komit (2PC) jedynie dla fazy koordynacji, podczas gdy rzeczywiste mutacje pozostają lokalne dla komórki. Klucze idempotencyjne zapewniają, że częściowe awarie podczas rozproszonych operacji mogą być bezpiecznie powtarzane bez podwajania wpływów finansowych. Dodatkowo, widoki materializowane w globalnej pamięci tylko do odczytu zapewniają ostatecznie spójne zapytania międzykomórkowe bez naruszania granic izolacji.
Jak radziłbyś sobie z przestrzeganiem przepisów dotyczących rezydencji danych (np. RODO, PCI DSS) w sytuacji, gdy komórki muszą obejmować granice geopolityczne dla odzyskiwania po awarii?
Wielu kandydatów pomija prawne implikacje dotyczące umiejscowienia komórek. Architektura wdraża komórki geofenced, w których główne przechowywanie danych pozostaje w granicach suwerennych, podczas gdy wtórne komórki działają jako szyfrowane gorące zapasowe z możliwościami kryptograficznego niszczenia. Techniki szyfrowania homomorficznego pozwalają algorytmom wykrywania oszustw działać na szyfrowanych danych przekraczających granice bez deszyfrowania wrażliwych PII w obcych jurysdykcjach. Routing ruchu komórkowego uwzględnia geolokalizowane DNS (Route 53 Geoproximity routing), aby zapewnić, że klienci z UE nigdy nie przechodzą przez komórki w USA, chyba że wyraźnie zezwolone na scenariusze odzyskiwania po awarii, a automatyczne audyty rezydencji danych weryfikują zgodność umiejscowienia komórek za pomocą skanowania Infrastructure as Code (IaC).
Jakie mechanizmy zapobiegają problemom z "herdem grzmotu", gdy usunięta komórka odzyskuje sprawność, a tysiące klientów jednocześnie próbują nawiązać ponownie połączenie, przytłaczając przywróconą instancję?
Ten subtelny problem operacyjny często jest pomijany. Rozwiązanie stosuje limitowanie stawki za pomocą tokenów na poziomie API Gateway specjalnie dla ponownego włączenia komórki, w połączeniu z eksponencjalnym opóźnieniem jitter w SDK klientów. Po odzyskaniu komórki, kontroler stopniowo zwiększa wagę routingu za pomocą interpolacji liniowej z 0% do 100% w ciągu 15-minutowego okna, jednocześnie monitorując p99 latencję i wskaźniki błędów. Pulowanie połączeń z adaptacyjnymi limitami równoległości w Envoy zapobiega wyczerpaniu połączeń, a zlecenia ocieplenia (transakcje syntetyczne) weryfikują zdrowie komórki przed akceptowaniem ruchu klientów. Zadania ocieplenia pamięci podręcznej proaktywnie zasilają klastry Redis w odzyskującej się komórce, aby zapobiec wystąpieniu efektu stada pamięci podręcznej podczas korzystania z zimnej pamięci.