Det viktigaste AWS-ingenjörsfusklappet: EC2 → servrar Lambda → fejkade servrar EBS-→hårddiskar S3 → långsamma hårddiskar VPC → LAN-cosplay IAM → tillstånd nekats CloudWatch → "vi har datadog hemma"

Kör aldrig frågor utan timeout. En enda rogue query eller load spike kan leda till stopp eller appstopp utan dem. Låt oss fundera på varför. Tänk på ett fall där en långvarig fråga oavsiktligt introduceras i vår app. Databasen behandlar vanligtvis bara kortlivade frågor (10 ms eller mindre) och plötsligt har vi en ny fråga som tar 1000 ms per exekvering. Detta kommer inte bara att sluka resurser, utan också skjuta i höjden antalet samtidiga transaktioner. Vi kommer antingen att nå anslutningsgränser, txn-gränser eller använda 100 % av databasens CPU/IOPs. Tänk nu på samma scenario, men vi sätter en 250 ms timeout på varje transaktion (databassidan), med exponentiell backoff-retry-logik + jitter (app-sidan). Vi har nu begränsat sprängradien för en enskild fråga. Långvariga frågor kommer att dödas, och backoff-logiken minimerar risken för åsnande hjordar. Genom att övervaka dessa timeouts kan vi snabbt identifiera den problematiska frågan och rulla tillbaka ändringen.

Write-ahead loggen (WAL) är både hur databaser snabbt committar och hur de säkert återhämtar sig från krascher. Utanför B-träd är det förmodligen den viktigaste strukturen i Postgres och MySQL. (det kallas "redo-loggen" i MySQL-land)