Baza pytań rekrutacyjnych i wiedzy. Filtruj, szukaj i sprawdzaj swoją wiedzę.
SOLID = 5 zasad projektowania OO. S (Single Responsibility): klasa/moduł ma jedną odpowiedzialność (jedno zadanie) i powinna zmieniać się z jednego powodu. O (Open/Closed): rozszerzasz bez modyfikacji istniejącego kodu. L (Liskov Substitution): podtyp jest podmienialny (ten sam kontrakt). I (Interface Segregation): małe interfejsy, bez nieużywanych metod. D (Dependency Inversion): zależ od abstrakcji; implementacje wstrzykuj (DI).
REST udostępnia wiele endpointów zasobów i zwraca stały kształt odpowiedzi, co może prowadzić do over/under‑fetchingu. GraphQL udostępnia pojedynczy endpoint i język zapytań, dzięki czemu klient pobiera dokładnie potrzebne pola i dane zagnieżdżone, ale kosztem większej złożoności schematu/resolverów i innego podejścia do cache.
Twierdzenie CAP mówi, że w systemie rozproszonym nie da się jednocześnie w pełni zagwarantować Consistency, Availability i Partition tolerance. Gdy wystąpi podział sieci, system musi wybrać między spójnością a dostępnością.
Typowe strategie load balancing to round‑robin, least connections, warianty ważone, IP‑hash/sticky sessions oraz consistent hashing. Load balancer może działać na warstwie L4 (TCP/UDP) lub L7 (HTTP) i używa health checków, aby omijać niezdrowe nody.
Architektura sterowana zdarzeniami (EDA) to styl, w którym komponenty komunikują się przez publikowanie i obsługę zdarzeń. Producenci wysyłają eventy do brokera, a konsumenci obsługują je asynchronicznie, co zmniejsza zależności i poprawia skalowalność kosztem spójności ostatecznej i trudniejszego śledzenia.
S: jedna odpowiedzialność na klasę (jeden powód zmiany); O: rozszerzaj zachowanie bez modyfikacji istniejącego kodu; L: podtyp ma dotrzymać kontraktu typu bazowego; I: małe, wyspecjalizowane interfejsy; D: zależ od abstrakcji, nie od konkretów (DI).
Idempotentność oznacza, że powtórzenie tego samego żądania daje ten sam efekt/stanie (np. wiele PUT ustawia zasób na tę samą wartość). To ważne przy retry.
Chcesz niskie sprzężenie (moduły jak najmniej zależą od siebie) i wysoką spójność (kod w module „należy do siebie”). To ułatwia zmiany: mniej efektów ubocznych i jaśniejsza odpowiedzialność.
DTO jest dopasowane do transportu/API, a model domenowy do reguł biznesowych. Rozdzielenie zmniejsza coupling między API a logiką i zapobiega „wyciekaniu” wewnętrznych pól/inwariantów.
CQRS rozdziela odczyty (query) od zapisów (command), często z różnymi modelami zoptymalizowanymi pod każde z nich. Pomaga, gdy potrzeby read i write mocno się różnią, ale dokłada złożoność.
Cache-aside: aplikacja czyta z cache, a przy miss pobiera z DB i uzupełnia cache; zapisy idą do DB, a cache aktualizujesz/invalidujesz. Write-through: zapis przechodzi przez cache, które zapisuje też do DB, utrzymując spójność cache kosztem opóźnienia zapisu.
2PC daje atomowy commit między serwisami, ale jest ciężkie i potrafi blokować przy awariach. Saga to sekwencja lokalnych transakcji z akcjami kompensacyjnymi — trade-off: mniej ścisłej spójności za większą dostępność i prostsze skalowanie.
Przyjmij idempotency key od klienta i zapisz wynik pod kluczem (użytkownik, key). Jeśli ten sam key przyjdzie ponownie, zwróć zapisany wynik zamiast tworzyć duplikaty.
Stosuj zmiany kompatybilne wstecz: dodawaj opcjonalne pola, nie usuwaj/nie zmieniaj nazw pól, a gdy musisz złamać kompatybilność — wersjonuj event. Konsumenci powinni ignorować nieznane pola i bezpiecznie obsługiwać brakujące.
Popularne strategie to token bucket i leaky bucket (albo fixed/sliding window). Limity możesz wymusić na edge/API gateway, load balancerze lub w aplikacji (per user/IP), najlepiej jak najbliżej wejścia.
Uwierzytelnianie odpowiada na „kim jesteś?” (potwierdzenie tożsamości). Autoryzacja odpowiada na „co możesz zrobić?” (uprawnienia) po uwierzytelnieniu.
Trzymaj logikę biznesową w centrum (domena/use case) i rozmawiaj ze światem przez porty (interfejsy). Adaptery implementują porty dla DB, HTTP, kolejek itd., dzięki czemu możesz zmieniać infrastrukturę bez przepisywania logiki.
Eventual consistency oznacza, że różne części systemu mogą przez chwilę pokazywać różne dane, ale finalnie się wyrównają. Dla użytkownika: „Zmiana jest zapisana; może pojawić się wszędzie po kilku sekundach — odśwież lub chwilę poczekaj.”
Offset pagination jest prosta (`page=10`), ale potrafi zwalniać dla dalekich stron i może pomijać/duplikować elementy, gdy dane się zmieniają. Cursor pagination używa stabilnego klucza „ostatnio widzianego”, skaluje się lepiej i jest bardziej spójna, ale jest trudniejsza dla klienta i nie wspiera łatwo „skoku na stronę 10”.
Wersjonuj, gdy wprowadzasz breaking change, którego nie da się zrobić kompatybilnie wstecz. Popularne strategie: wersja w URL (`/v2/...`) albo w nagłówkach/content negotiation. Jeśli się da, preferuj zmiany kompatybilne wstecz (dodawanie pól opcjonalnych).
SLI to mierzalna metryka jakości usługi (np. dostępność, latencja, error rate). To liczba, którą śledzisz, żeby rozumieć niezawodność.
SLO (Service Level Objective) to cel dla SLI (np. 99,9% dostępności). Error budget to „budżet błędów”, czyli dopuszczalny margines (100% - SLO). Używa się go do balansowania rozwoju funkcji vs poprawy niezawodności.
Średnia ukrywa tail latency: kilka bardzo wolnych requestów może nie być widocznych w średniej, ale użytkownik je odczuje. p95/p99 pokazuje zachowanie najwolniejszych 5%/1% i pomaga wykryć kolejki oraz nasycenie.
Dobry alert jest „actionable” i skupiony na wpływie na użytkownika (symptom-based), ma jasną ważność i link do runbooka. Alert fatigue ograniczasz przez usuwanie szumu, dobre progi, grupowanie i budzenie tylko przy realnych incydentach (pomaga error budget).
Blameless postmortem skupia się na tym, co się stało i jak ulepszyć system, a nie na szukaniu winnego. Daje konkretne action itemy (fixy, alerty, runbooki) i buduje kulturę, w której ludzie szybko zgłaszają problemy.
Serwis stateless trzyma stan requestu poza instancją (np. w DB/Redis), więc każda instancja może obsłużyć każdy request. Serwis stateful trzyma stan w pamięci konkretnej instancji, co utrudnia skalowanie i failover (potrzebujesz sticky sessions albo replikacji stanu).
NFR opisują jak system ma się zachowywać, a nie jakie ma funkcje. Przykłady: wydajność (np. p95), dostępność, bezpieczeństwo, skalowalność, obserwowalność i zgodność (compliance). NFR mocno wpływają na decyzje architektoniczne.
Bounded context to granica, w której model domenowy i pojęcia mają jedno spójne znaczenie. Pomaga zmniejszyć sprzężenie, bo nie próbujesz mieć jednego “mega modelu” na wszystko, i ułatwia wyznaczanie granic zespołów, serwisów lub modułów.
Cache stampede to sytuacja, gdy wiele requestów naraz trafia na cache miss (często po wygaśnięciu wpisu), więc wszystkie uderzają w bazę. Mitigacje: jitter TTL, “single flight”/lock per key, stale-while-revalidate oraz podgrzewanie (warming) krytycznych kluczy.
Graceful degradation oznacza, że system dalej działa w trybie “okrojonym”, gdy część elementów padnie (np. pokaż cached dane, gdy rekomendacje są niedostępne). Projektuj to przez timeouty, fallbacki, circuit breakery, feature flagi oraz jasne komunikaty dla użytkownika o ograniczeniach.
CORS to reguła przeglądarki, która mówi, z jakich originów JavaScript może odczytać odpowiedź z Twojego API. To nie jest uwierzytelnianie i nie blokuje wywołań z serwera ani narzędzi typu curl. Nadal potrzebujesz poprawnego auth/authz i walidacji po stronie serwera.
Reverse proxy stoi „przed” Twoimi serwerami aplikacji i przekazuje do nich requesty klientów. Zwykle używa się go do terminacji TLS, routingu, load balancingu, cache/compress oraz czasem rate limitów lub reguł WAF.
ADR to krótki dokument opisujący decyzję architektoniczną: kontekst, rozważone opcje, wybór i konsekwencje. Jest przydatny, bo zapisuje „dlaczego” coś wybrano, ułatwia onboarding i zmniejsza powracające dyskusje po kilku miesiącach.
Event sourcing zapisuje stan jako sekwencję zdarzeń (faktów), a aktualny stan odtwarzasz przez ich replay do projekcji. Plusy: audyt, pełna historia i „time travel” do debugowania. Minusy: większa złożoność, ewolucja schematów eventów, dodatkowe projekcje oraz trudniejsze zapytania ad-hoc.
Anti-corruption layer to warstwa tłumacząca na granicy, która chroni Twój model domenowy przed „przeciekaniem” pojęć z systemu legacy lub zewnętrznego. Stosujesz ją, gdy integrujesz się z czymś o innym modelu albo brzydkim API, żeby rdzeń pozostał czysty, a mapowanie było w jednym miejscu.