Základní technický list pro inženýrství AWS: EC2 → servery Lambda → falešné servery EBS → pevné disky S3 → pomalé pevné disky VPC → LAN cosplay IAM → povolení zamítnuto CloudWatch → "máme doma datadog"

Nikdy nespouštějte dotazy bez timeoutu. Jeden neautorizovaný dotaz nebo náskok načtení může bez nich vést k zaseknutím nebo výpadku aplikace. Pojďme si to ujasnit. Zvažme případ, kdy se do naší aplikace omylem dostane dlouhodobý dotaz. Databáze obvykle zpracovává pouze krátkodobé dotazy (10ms nebo méně) a najednou máme nový dotaz, který trvá 1000ms na jedno vykonání. To nejenže zabere zdroje, ale také výrazně zvýší počet současných transakcí. Buď dosáhneme limitů připojení, limitů TXN, nebo využijeme 100 % procesoru databáze / IOPS. Nyní uvažujte stejný scénář, ale na každou transakci (na straně databáze) ukládáme timeout 250ms, s exponenciálním zpětným pokusem + jitterem (na straně aplikace). Nyní jsme omezili dosah výbuchu u jakéhokoli jednotlivého dotazu. Dlouhodobé dotazy budou zrušeny a logika ustupování minimalizuje riziko hromadného hromadění. Sledováním těchto časových limitů můžeme rychle identifikovat problematický dotaz a vrátit změnu zpět.

Write-ahead log (WAL) je jak způsob, jak databáze rychle fungují, tak i bezpečný způsob, jak se zotavují po pádech. Mimo B-stromy je to pravděpodobně nejdůležitější struktura v Postgresu a MySQL. (v MySQL se tomu říká "redo log")