La scheda informativa essenziale per l'ingegneria AWS: EC2 → server Lambda → server finti EBS → dischi rigidi S3 → dischi rigidi lenti VPC → cosplay di LAN IAM → permesso negato CloudWatch → "abbiamo datadog a casa"

Non eseguire mai query senza un timeout. Una singola query fuori controllo o un picco di carico possono portare a blocchi o inattività dell'app senza di essi. Pensiamo a perché. Considera il caso in cui una query a lungo termine viene introdotta involontariamente nella nostra app. Il database di solito elabora solo query di breve durata (10 ms o meno) e improvvisamente abbiamo una nuova query che richiede 1000 ms per esecuzione. Non solo questo consumerà risorse, ma aumenterà il numero di transazioni simultanee. Rischiamo di raggiungere i limiti di connessione, i limiti di transazione o di utilizzare il 100% della CPU / IOPS del database. Ora considera lo stesso scenario, ma poniamo un timeout di 250 ms su ogni transazione (lato database), con logica di retry con backoff esponenziale + jitter (lato app). Abbiamo ora limitato il raggio d'azione di qualsiasi singola query. Le query a lungo termine verranno terminate, e la logica di backoff riduce al minimo il rischio di mandrie in tempesta. Monitorando questi timeout, possiamo identificare rapidamente la query problematica e annullare la modifica.

Il write-ahead log (WAL) è sia il modo in cui i database effettuano commit rapidamente sia il modo in cui recuperano in modo sicuro da crash. Al di fuori degli B-tree, è probabilmente la struttura più importante in Postgres e MySQL. (è chiamato "redo log" nel mondo di MySQL)