De essentiële AWS engineering cheatsheet: EC2 → servers Lambda → nepservers EBS → harde schijven S3 → trage harde schijven VPC → LAN cosplay IAM → toegang geweigerd CloudWatch → "we hebben datadog thuis"

Voer nooit queries uit zonder een time-out. Een enkele kwaadaardige query of piek in de belasting kan leiden tot stilstand of downtime van de app zonder hen. Laten we nadenken over waarom. Overweeg het geval waarin een langlopende query per ongeluk in onze app wordt geïntroduceerd. De database verwerkt doorgaans alleen kortdurende queries (10 ms of minder) en plotseling hebben we een nieuwe query die 1000 ms per uitvoering kost. Dit zal niet alleen middelen verbruiken, maar ook het aantal gelijktijdige transacties verhogen. We zullen ofwel de verbindingslimieten, txn-limieten bereiken, of 100% van de database-CPU / IOPS gebruiken. Overweeg nu hetzelfde scenario, maar we plaatsen een time-out van 250 ms op elke transactie (databasezijde), met exponentiële backoff-retrylogica + jitter (app-zijde). We hebben nu de impact van een enkele query beperkt. Langlopende queries worden beëindigd, en de backoff-logica minimaliseert het risico van donderscharen. Door deze time-outs te monitoren, kunnen we snel de problematische query identificeren en de wijziging terugdraaien.

Het write-ahead log (WAL) is zowel hoe databases snel committen als hoe ze veilig herstellen van crashes. Buiten B-bomen is het waarschijnlijk de belangrijkste structuur in Postgres en MySQL. (het wordt de "redo log" genoemd in MySQL-land)