Mikroserwisy
Baza pytań rekrutacyjnych i wiedzy. Filtruj, szukaj i sprawdzaj swoją wiedzę.
mediumarchitecturemicroservicesmonolith+1
Odpowiedź
Monolit to jedna wdrażalna aplikacja ze wspólnym runtime i zwykle jedną bazą danych — łatwiejsza w budowie i debugowaniu, ale trudniejsza do niezależnego skalowania fragmentów. Mikroserwisy dzielą system na niezależnie wdrażalne usługi, które mogą skalować się i rozwijać osobno, ale dodają złożoność systemów rozproszonych i narzut operacyjny.
mediummicroservicestradeoffsscalability+1
Odpowiedź
Korzyści to niezależne wdrażanie i skalowanie usług, autonomia zespołów i elastyczność technologiczna. Kompromisy to złożoność systemów rozproszonych, opóźnienia sieciowe, trudniejsze debugowanie/observability oraz wyzwania spójności ostatecznej.
mediumcommunicationrestgrpc+1
Odpowiedź
Mikroserwisy komunikują się synchronicznie przez REST/gRPC, gdzie wywołujący czeka na odpowiedź, albo asynchronicznie przez messaging/eventy. Synchroniczna komunikacja jest prostsza, ale mocniej wiąże usługi i przenosi awarie; asynchroniczna zwiększa odporność kosztem spójności ostatecznej i większej złożoności.
mediumservice-discoveryregistrykubernetes+1
Odpowiedź
Service discovery to mechanizm dynamicznego odnajdywania instancji usług (np. przez rejestr Eureka/Consul lub DNS w Kubernetes). Jest potrzebny, bo instancje skalują się i zmieniają adresy, więc klienci muszą znajdować zdrowe endpointy w runtime.
hardsagaoutboxconsistency+1
Odpowiedź
Spójność w mikroserwisach jest zwykle ostateczna. Sagi koordynują serię lokalnych transakcji z akcjami kompensacyjnymi przy błędzie. Wzorzec outbox zapisuje eventy w tej samej transakcji DB co zmiana stanu, a potem niezawodnie publikuje je do brokera.
easymicroservicesarchitecturebounded-context
Odpowiedź
Mikroserwis to mały, niezależnie wdrażalny serwis, który posiada fragment funkcji biznesowej i swoje dane. Celem jest niezależna zmiana i skalowanie, ale trade-off to złożoność systemu rozproszonego.
easyapi-gatewayroutingsecurity
Odpowiedź
To jedno wejście przed serwisami: routing, auth, rate limiting, TLS termination i agregacja requestów. Upraszcza klientów, ale może stać się wąskim gardłem, jeśli jest przeciążone.
easyservice-discoverydnsregistry
Odpowiedź
W środowiskach dynamicznych (autoscaling) instancje przychodzą i odchodzą. Service discovery pozwala klientom znajdować zdrowe instancje (registry/DNS) bez hardcodowania IP.
mediumcommunicationhttpmessaging+1
Odpowiedź
Synchroniczne wywołania (HTTP/gRPC) są prostsze i dają natychmiastową odpowiedź, ale zwiększają coupling i mogą powodować kaskadowe awarie. Asynchroniczne messaging poprawia decoupling i odporność, ale dokłada eventual consistency i złożoność operacyjną (kolejki, retry, kolejność).
mediumcircuit-breakerresiliencetimeouts
Odpowiedź
Na jakiś czas przestaje wywoływać padającą zależność (stan open) i „failuje szybko”, chroniąc serwis i dając zależności czas na powrót. Zmniejsza kaskadowe awarie i poprawia stabilność.
mediumtracingobservabilitycorrelation-id
Odpowiedź
Trace reprezentuje jedno żądanie przechodzące przez serwisy, a span to zmierzona operacja w ramach trace. Correlation/trace ID pozwala spiąć logi, metryki i spany między serwisami, co mocno przyspiesza debugowanie.
hardoutboxeventsconsistency+1
Odpowiedź
Zapisuje event/wiadomość do tabeli „outbox” w tej samej transakcji co zmiana biznesowa, a potem publikuje asynchronicznie. Dzięki temu nie gubisz eventów, gdy commit w DB się uda, ale publikacja zawiedzie.
hardidempotencymessagingretries
Odpowiedź
Bo wiadomości mogą przyjść więcej niż raz (retry, redelivery). Idempotentny konsument bezpiecznie obsługuje duplikaty (np. dedup key lub upsert), żeby nie robić podwójnych efektów ubocznych.
hardcontractsversioningbackward-compatibility
Odpowiedź
Preferuj zmiany kompatybilne wstecz (dodawaj opcjonalne pola, nie usuwaj/nie zmieniaj nazw), a gdy trzeba — wersjonuj. Kontrakty weryfikuj testami consumer-driven i wdrażaj w kolejności, która utrzyma kompatybilność w trakcie rollout.
hardresiliencetimeoutsbulkhead+1
Odpowiedź
Używaj timeoutów + circuit breakerów oraz ograniczaj retry (backoff + jitter). Dodatkowo stosuj bulkheady (limity współbieżności na zależność), żeby jedna awaria nie wyczerpała wszystkich wątków/połączeń.
easytimeoutsresiliencecascading-failures
Odpowiedź
Bez timeoutów requesty mogą wisieć i zużywać wątki/połączenia, co prowadzi do kaskadowych awarii. Timeout pozwala szybko failować, odzyskać zasoby i bezpiecznie zastosować retry lub fallback.
mediumbackpressurequeuesstreams+1
Odpowiedź
Backpressure to mechanizm sygnalizacji „zwolnij”, gdy producent generuje szybciej niż konsument przetwarza. Pojawia się w strumieniach, systemach kolejkowych i API — bez niego rosną kolejki, zużycie pamięci i timeouty.
mediumschema-registryeventscompatibility+1
Odpowiedź
Schema registry przechowuje i wersjonuje schematy eventów (Avro/Protobuf/JSON schema) oraz wymusza reguły kompatybilności. Pomaga producentom i konsumentom bezpiecznie ewoluować bez wzajemnego psucia się.
hardbulkheadresilienceconcurrency+1
Odpowiedź
Bulkhead izoluje zasoby, żeby jedna padająca zależność nie wyczerpała wszystkiego. W praktyce: osobne pule wątków, pule połączeń albo limity współbieżności per zależność, dzięki czemu reszta systemu nadal działa.
harddistributed-lockcoordinationreliability
Odpowiedź
Distributed lock jest potrzebny, gdy wiele instancji musi zagwarantować, że tylko jedna wykona sekcję krytyczną (np. jeden job schedulera). Ryzyka: wycieki locków, split-brain, problemy zegara/sieci i dodatkowe opóźnienie; jeśli się da, preferuj idempotencję i constrainty w DB.
easyshared-databasecouplingdata-ownership
Odpowiedź
To sprzęga serwisy przez wspólny schemat i transakcje: jedna zmiana może zepsuć inne, wdrożenia trzeba koordynować, a własność danych jest niejasna. Trudniej też o skalowanie i granice bezpieczeństwa.
mediumcontractseventsapi+1
Odpowiedź
Przez API (request/response) albo eventy (publish/subscribe). Serwis jest właścicielem swoich danych i wystawia je przez stabilny kontrakt; inne serwisy mogą budować read modele lub cache na podstawie eventów, jeśli potrzebują lokalnych odczytów.
mediumretriesbackoffjitter+1
Odpowiedź
Retry storm to sytuacja, gdy wiele klientów robi retry jednocześnie, zwiększając obciążenie padającej zależności i utrudniając jej powrót. Zapobiegasz przez exponential backoff + jitter, limity retry, circuit breakery i rate limiting.
hardidempotencydeduplicationmessaging+1
Odpowiedź
Zakładaj duplikaty i zrób handler idempotentny. Typowe wzorce: zapisz ID wiadomości jako przetworzone z unique constraint, użyj upsertów i trzymaj zmianę + dedup w jednej transakcji (tabela inbox/dedup).
hardsagaorchestrationchoreography+1
Odpowiedź
Orkiestracja ma centralnego koordynatora, który mówi serwisom co robić dalej. Choreografia jest zdecentralizowana: serwisy reagują na eventy i uruchamiają kolejny krok. Orkiestracja jest łatwiejsza do ogarnięcia, a choreografia zmniejsza centralne sprzężenie, ale bywa trudniejsza do śledzenia.
easymicroservicestestingcontracts+1
Odpowiedź
W consumer-driven contract testing konsument definiuje oczekiwania wobec API (kształt request/response), a provider weryfikuje, że nadal je spełnia. To wcześnie wykrywa breaking changes i pomaga zespołom wdrażać się niezależnie z większą pewnością.
mediummicroservicessecuritymtls+1
Odpowiedź
mTLS szyfruje ruch i uwierzytelnia obie strony (tożsamość serwisu), co pomaga przed podszywaniem i podsłuchem. Samo mTLS NIE rozwiązuje autoryzacji (co serwis może robić) i nie zastępuje walidacji wejścia ani reguł bezpieczeństwa na poziomie biznesowym.
mediummicroservicessagacompensation+1
Odpowiedź
Akcja kompensująca to operacja biznesowa, która “odwraca” poprzedni krok (np. anuluj rezerwację, gdy płatność się nie powiedzie). To trudne, bo to nie jest prawdziwy rollback: może się nie udać, nie zawsze idealnie przywróci stan, i musi być idempotentne oraz dobrze obserwowalne.
hardmicroservicesrate-limitingredis+1
Odpowiedź
Przy wielu instancjach licznik w pamięci limituje tylko jedną instancję, więc sumaryczny ruch może przekroczyć limit. Zwykle potrzebujesz współdzielonego storage (np. Redis) albo limitów na gatewayu. Trudne elementy: poprawność przy współbieżności, okna czasowe, drift zegara i unikanie “hot keys”.
hardmicroservicesmulti-regionavailability+1
Odpowiedź
Korzyści: większa dostępność i mniejsza latencja dla globalnych użytkowników. Problemy: replikacja danych, spójność/rozwiązywanie konfliktów, większa złożoność operacyjna oraz latencja/koszt między regionami. Wiele zespołów zaczyna od active-passive (failover) zanim przejdzie do active-active.
easymicroservicesbffapi+1
Odpowiedź
BFF to backend dopasowany do jednego frontu (np. web, mobile). Pomaga, gdy różne klienty potrzebują innego „kształtu” danych, gdy chcesz ograniczyć „chatty” wywołania z UI, albo gdy potrzebujesz miejsca do złożenia wielu wywołań serwisów w jedno API dla tego klienta.
mediummicroservicesgrpcrest+2
Odpowiedź
REST (JSON po HTTP) jest łatwe do debugowania i bardzo kompatybilne. gRPC używa HTTP/2 + Protobuf: daje silny kontrakt, dobrą wydajność i streaming, ale trudniej je „podejrzeć” bez narzędzi i jest mniej przyjazne przeglądarce. Wybór zależy od kompatybilności, potrzeb wydajności i dojrzałości zespołu/narzędzi.
mediummicroservicesfan-outlatency+2
Odpowiedź
Zwiększa latencję (czekasz na wiele calli), zwiększa ryzyko awarii (jeden zależny serwis psuje cały request) i potrafi mnożyć obciążenie. Ograniczaj to przez agregację w BFF/API Gateway, cache, podejście async/event-driven oraz time-outy + bulkheady, żeby jeden wolny serwis nie blokował reszty.
hardmicroserviceskafkaordering+2
Odpowiedź
Kafka gwarantuje kolejność tylko w obrębie jednej partycji. Żeby zdarzenia dla danej encji były po kolei, publikuj je z tym samym kluczem partycjonowania (np. `orderId`), żeby trafiły do tej samej partycji. Nie ma globalnej kolejności między partycjami, a konsument i tak powinien obsłużyć duplikaty/retry.
hardmicroservicesobservabilitytracing+1
Odpowiedź
`traceparent` to nagłówek W3C Trace Context, który niesie trace ID i informację o rodzicu (span). Gdy każdy serwis przekazuje go dalej w wywołaniach downstream, możesz połączyć logi/span’y w jeden end-to-end trace i łatwiej debugować opóźnienia/awarie między serwisami.
GET /api/orders/123 HTTP/1.1
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01