Välttämätön AWS:n insinööritieto: EC2 → palvelimet Lambda → väärennetyt palvelimet EBS → kovalevyt S3 → hitaat kovalevyt VPC → LAN cosplay IAM → lupa evätty CloudWatch → "meillä on datadog kotona"

Älä koskaan aja kyselyitä ilman aikalisää. Yksi vilpillinen kysely tai latauspiikki voi johtaa pysähtymisiin tai sovellusten käyttökatkoihin ilman niitä. Mietitään miksi. Tarkastellaan tilannetta, jossa pitkäaikainen kysely päätyy vahingossa sovellukseemme. Tietokanta käsittelee tyypillisesti vain lyhytikäisiä kyselyitä (10 ms tai vähemmän), ja yhtäkkiä meillä on uusi kysely, joka vie 1000 ms per suoritus. Tämä ei ainoastaan vie resursseja, vaan myös lisää samanaikaisten tapahtumien määrää. Saavutamme joko yhteysrajat, txn-rajat tai käytämme 100 % tietokannan prosessorista / IOPS:sta. Tarkastellaan nyt samaa skenaariota, mutta asetamme jokaiselle transaktiolle (tietokantapuoli) 250 ms aikakatkaisun, eksponentiaalisella takaiskun uudelleenyrittämislogiikalla + jitterillä (sovelluspuoli). Olemme nyt rajoittaneet yksittäisen kyselyn räjähdysaluetta. Pitkäkestoiset kyselyt kuolevat, ja perääntymislogiikka minimoi jylisevien laumojen riskin. Seuraamalla näitä aikakatkaisuja voimme nopeasti tunnistaa ongelmallisen kyselyn ja peruuttaa muutoksen.

Write-ahead log (WAL) on sekä tapa sitoutua tietokannat nopeasti että miten ne palautuvat turvallisesti kaatumisista. B-puiden ulkopuolella se on luultavasti tärkein rakenne Postgresissa ja MySQL:ssä. (MySQL-landissa sitä kutsutaan "uudelleenlokiksi")