Architektura
Baza pytań rekrutacyjnych i wiedzy. Filtruj, szukaj i sprawdzaj swoją wiedzę.
mediumdesign-principlessolidoop+1
Odpowiedź
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).
mediumapirestgraphql+1
Odpowiedź
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.
harddistributed-systemstheoryconsistency+1
Odpowiedź
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ą.
mediumload-balancingperformancescalability
Odpowiedź
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.
mediumevent-drivenarchitecturemessaging+1
Odpowiedź
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.
easysoliddesign-principlesoop
Odpowiedź
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).
easyhttpidempotencyapi
Odpowiedź
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.
easycouplingcohesiondesign
Odpowiedź
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ść.
mediumdtodomain-modelapi-design
Odpowiedź
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.
mediumcqrsarchitectureread-model
Odpowiedź
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ść.
mediumcachecache-asidewrite-through+1
Odpowiedź
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.
hardsaga2pcdistributed-transactions
Odpowiedź
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.
hardidempotencyapiretries
Odpowiedź
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.
hardeventsschema-evolutionbackward-compatibility
Odpowiedź
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.
hardrate-limitingtoken-bucketapi-gateway
Odpowiedź
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.
easyauthauthenticationauthorization+1
Odpowiedź
Uwierzytelnianie odpowiada na „kim jesteś?” (potwierdzenie tożsamości). Autoryzacja odpowiada na „co możesz zrobić?” (uprawnienia) po uwierzytelnieniu.
mediumhexagonalports-adaptersclean-architecture+1
Odpowiedź
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.
mediumconsistencydistributed-systemseventual-consistency
Odpowiedź
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.”
hardpaginationcursoroffset+1
Odpowiedź
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”.
hardapi-versioningbackward-compatibilityrest
Odpowiedź
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).
easyslireliabilitymetrics
Odpowiedź
SLI to mierzalna metryka jakości usługi (np. dostępność, latencja, error rate). To liczba, którą śledzisz, żeby rozumieć niezawodność.
mediumsloerror-budgetreliability
Odpowiedź
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.
mediumlatencyp99performance+1
Odpowiedź
Ś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.
hardalertingrunbookobservability+1
Odpowiedź
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).
hardpostmortemincidentculture+1
Odpowiedź
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.
easyarchitecturestatelessstateful+1
Odpowiedź
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).
mediumarchitecturenfrquality-attributes+1
Odpowiedź
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.
mediumarchitecturedddbounded-context+1
Odpowiedź
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.
hardarchitecturecachingcache-stampede+1
Odpowiedź
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.
hardarchitectureresiliencefallbacks+1
Odpowiedź
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.
easyarchitecturewebcors+1
Odpowiedź
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.
mediumarchitecturereverse-proxyhttp+1
Odpowiedź
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.
mediumarchitecturedocumentationdecisions+1
Odpowiedź
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.
hardarchitectureevent-sourcingevents+1
Odpowiedź
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.
hardarchitecturedddintegration+1
Odpowiedź
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.