“Gdyby budowlańcy budowali domy w taki sam sposób, w jaki programiści piszą programy, to jeden dzięcioł zniszczyłby całą cywilizację”.
Ten dzięcioł to chociażby jedno zbłąkane zapytanie do bazy pozbawione limitu czasu.
Lub to malutkie API do wyświetlenia nic nieznaczącego znaczka w stopce strony.
Bez którego nie wyświetla się cała aplikacja.
I też te niewinne pliki tymczasowe, które niepostrzeżenie odkładają się na dysku w setkach tysięcy sztuk?
A co gdy dzięcioł uderzy przez przypadek dwa razy?
Czy pobierzemy pieniądze z karty dwukrotnie?
Nie mówię tu o czarnych łabędziach.
Ale o dzięciołach, które nawet jeśli pojawią się raz na milion, to przy tysiącu transakcji na sekundę zobaczymy je średnio… co kwadrans.
Spędzamy mnóstwo czasu implementując tzw. _happy path_.
A czasem nawet ją testując.
A tak niewiele czasu poświęcamy potencjalnym błędom i temu, jak zareaguje na nie aplikacja.
Chciałbym się z wami podzielić sprawdzonymi technikami, jak znajdować i zabezpieczać się przed niebezpiecznymi miejscami w kodzie.
Pokażę kilkanaście gotowych i sprawdzonych wzorców i porad, m.in.:
* łapanie wyjątków i ponawianie
* circuit breaker i bulk heading
* idempotencja, deduplikacja i _outbox pattern_
* dry-run, graceful degradation i sharding
* i jak to wszystko przetestować
Świat nie jest idealny i nasz kod nie jest idealny.
Przestańmy udawać, że jest inaczej.
I budujmy systemy, które same potrafią się uleczyć, zamiast ciągle budzić nas w nocy alertami.