Scenariusze

Endpoint API działa 5 sekund. Jak to diagnozujesz?

Sprawdzam logi/APM czy problem jest w kodzie aplikacji czy w zależności (baza, zewnętrzne API), włączam profiler/query log, patrzę na EXPLAIN wolnych zapytań i liczbę zapytań (N+1), dopiero potem optymalizuję konkretne miejsce.

API nagle zaczyna zwracać 500. Co sprawdzasz najpierw?

Logi aplikacji z ostatnich minut, czy był właśnie deploy lub zmiana configu, status zależności (baza, cache, kolejka, zewnętrzne API), i czy da się to odtworzyć na staging.

Masz N+1 w Eloquent. Jak je znajdujesz i naprawiasz?

Włączam DB: enableQueryLog() albo Laravel Debugbar, widzę powtarzające się zapytania per wiersz, naprawiam przez eager loading with() dla konkretnej relacji, w testach zabezpieczam licznik zapytań.

Dwie osoby jednocześnie rezerwują ten sam termin. Jak zapobiegasz podwójnej rezerwacji?

Unique constraint na kolumnie termin/slot w bazie jako ostateczna gwarancja, plus pesymistyczne blokowanie (SELECT ... FOR UPDATE) albo optymistyczne blokowanie z wersją przy samym zapisie rezerwacji.

Endpoint ma zwrócić 100 000 rekordów. Jak go projektujesz?

Nie zwracam wszystkiego naraz - paginacja, najlepiej cursor-based przy dużych zbiorach, streaming/chunking odpowiedzi jeśli to eksport, i limit na rozmiar strony wymuszony po stronie API.

Job w kolejce wykonał się dwa razy. Jak zabezpieczasz operację?

Projektuję job jako idempotentny - np. unique constraint w bazie, sprawdzenie stanu przed wykonaniem operacji, albo klucz idempotencji per żądanie, zamiast zakładać exactly-once delivery.

Zapytanie SQL jest wolne. Jak je optymalizujesz?

Najpierw EXPLAIN, żeby zobaczyć czy używa indeksu (type=ALL to sygnał alarmowy), potem dodaję lub poprawiam indeks pod realny WHERE/ORDER BY, sprawdzam czy nie ma funkcji na kolumnie blokującej indeks, na końcu mierzę różnicę przed i po.

Jak zaprojektować cache dla często odczytywanych, rzadko zmienianych danych?

Cache-aside z Redis - czytam z cache, przy miss czytam bazę i zapisuję wynik z TTL, invaliduję/nadpisuję cache przy zapisie danych źródłowych zamiast czekać na wygaśnięcie TTL.

Kiedy użyć Redis, a kiedy MySQL dla danego problemu?

Redis gdy potrzebna jest bardzo szybka struktura w pamięci (cache, licznik, rate limiting, kolejka, leaderboard) bez twardych gwarancji trwałości, MySQL gdy potrzebna jest trwałość, relacje i transakcyjność ACID.

Kiedy w ogóle użyć kolejki zamiast wykonać coś synchronicznie?

Gdy operacja jest wolna albo niepewna względem czasu odpowiedzi requestu (mail, webhook, generowanie raportu) albo gdy chcemy oddzielić skalowanie producenta od przetwarzania - użytkownik nie powinien czekać na coś, co nie musi być natychmiastowe.

Jak zaimplementować retry z exponential backoff przy wywołaniu zewnętrznego API?

Ograniczona liczba prób (np. 3), rosnące opóźnienie między próbami (np. 1s/2s/4s), retry tylko dla błędów przejściowych (timeout, 5xx), nigdy dla 4xx, docelowo z jitterem żeby uniknąć thundering herd.

Jak zabezpieczyć endpoint API przed nadużyciami?

Autentykacja i autoryzacja na poziomie konkretnego zasobu, nie tylko sprawdzenie czy zalogowany, walidacja wejścia, rate limiting per user/IP i logowanie prób bez ujawniania szczegółów w treści błędu.

Jak obsłużyć race condition przy równoległej aktualizacji tego samego rekordu?

Pesymistyczne blokowanie gdy konflikty są częste (SELECT ... FOR UPDATE), optymistyczne blokowanie (kolumna wersji) gdy konflikty są rzadkie - w obu przypadkach unikam wzorca odczytaj-sprawdź-zapisz bez blokady.

Jak zaprojektować idempotentny endpoint, np. tworzenie płatności?

Klient przesyła idempotency key w nagłówku, serwer sprawdza czy już przetworzył request z tym kluczem i jeśli tak, zwraca zapisany wcześniej wynik zamiast wykonywać operację ponownie.

Jak diagnozujesz problem na produkcji krok po kroku?

Logi i monitoring żeby zlokalizować zakres problemu, sprawdzenie korelacji z deployem lub zmianą configu, próba reprodukcji na mniejszym środowisku, szybki hotfix lub rollback, dopiero potem pełna root cause analysis.

Co robisz zaraz po nieudanym deployu na produkcji?

Szybka ocena czy szybciej naprawić do przodu czy zrobić rollback, komunikacja do zespołu o stanie, rollback jeśli błąd jest krytyczny, dopiero potem analiza przyczyny zanim spróbuję ponownie.

Jak zaprojektować transakcję obejmującą kilka operacji zapisu?

Grupuję operacje w jedną transakcję bazodanową tak, żeby były atomowe, trzymam transakcję jak najkrótszą i unikam w niej wywołań zewnętrznych API czy długich operacji.

Redis przestaje działać. Co dzieje się z aplikacją i jak się zabezpieczyć?

Zależy od roli - jako cache aplikacja robi fallback do bazy (cache-aside), jako session store/kolejka to twardy błąd. Warto mieć Sentinel/replikację i timeouty + połączenia zamiast wieszania requestu.