Podstawowa ściągawka inżynieryjna AWS: EC2 → serwery Lambda → fałszywe serwery EBS → dyski twarde S3 → wolne dyski twarde VPC → cosplay LAN IAM → dostęp zabroniony CloudWatch → "mamy datadoga w domu"

Nigdy nie uruchamiaj zapytań bez limitu czasu. Pojedyncze nieprawidłowe zapytanie lub skok obciążenia mogą prowadzić do zastoju lub przestoju aplikacji bez nich. Zastanówmy się, dlaczego. Rozważmy przypadek, w którym do naszej aplikacji przypadkowo wprowadzone zostaje długoterminowe zapytanie. Baza danych zazwyczaj przetwarza tylko krótkotrwałe zapytania (10 ms lub mniej), a nagle mamy nowe zapytanie, które zajmuje 1000 ms na wykonanie. Nie tylko zajmie to zasoby, ale także zwiększy liczbę jednoczesnych transakcji. Możemy osiągnąć limity połączeń, limity transakcji lub wykorzystać 100% CPU / IOPS bazy danych. Teraz rozważmy ten sam scenariusz, ale nakładamy limit czasu 250 ms na każdą transakcję (po stronie bazy danych), z logiką ponownego próbowania z wykładniczym opóźnieniem + jitter (po stronie aplikacji). Ograniczyliśmy teraz zasięg wpływu pojedynczego zapytania. Długoterminowe zapytania zostaną zakończone, a logika opóźnienia minimalizuje ryzyko tzw. „thundering herds”. Monitorując te limity czasu, możemy szybko zidentyfikować problematyczne zapytanie i cofnąć zmianę.

Dziennik zapisu (WAL) to sposób, w jaki bazy danych szybko dokonują zapisów i jak bezpiecznie odzyskują się po awariach. Poza B-drzewami, to prawdopodobnie najważniejsza struktura w Postgres i MySQL. (w MySQL nazywa się to "dziennikiem ponownego zapisu")