Det essensielle AWS ingeniør-jukselappen: EC2 → servere Lambda → falske servere EBS → harddisker S3 → trege harddisker VPC → LAN-cosplay IAM → tillatelse avslått CloudWatch → «vi har datadog hjemme»

Kjør aldri spørringer uten timeout. En enkelt rogue-spørring eller belastningsspike kan føre til stopp eller nedetid i appen uten dem. La oss tenke gjennom hvorfor. Tenk på et tilfelle der en langvarig spørring utilsiktet blir introdusert i appen vår. Databasen behandler vanligvis bare kortvarige spørringer (10 ms eller mindre), og plutselig har vi en ny spørring som tar 1000 ms per kjøring. Dette vil ikke bare sluke ressurser, men også øke antallet samtidige transaksjoner. Vi vil enten treffe tilkoblingsgrenser, txn-grenser, eller bruke 100 % av databasens CPU / IOPs. Tenk nå på samme scenario, men vi setter en 250 ms timeout på hver transaksjon (database-siden), med eksponentiell backoff-retry-logikk + jitter (app-side). Vi har nå begrenset sprengradiusen til en enkelt forespørsel. Langvarige forespørsler blir drept, og backoff-logikken minimerer risikoen for tordnende flokker. Ved å overvåke disse timeoutene kan vi raskt identifisere den problematiske spørringen og rulle tilbake endringen.

Write-ahead loggen (WAL) er både hvordan databaser forplikter seg raskt og hvordan de trygt kommer seg etter krasj. Utenom B-trær er det sannsynligvis den viktigste strukturen i Postgres og MySQL. (det kalles "re-loggen" i MySQL-land)