Основний шпаргалка з інженерії AWS: Сервери EC2 → Lambda → фейкові сервери EBS → жорсткі диски S3 → повільні жорсткі диски VPC → LAN косплей IAM → дозвіл відхилено CloudWatch → «у нас є datadog вдома»

Ніколи не виконуйте запити без тайм-ауту. Один випадковий запит або стрибок завантаження можуть призвести до затримок або простою додатку без них. Давайте подумаємо чому. Розглянемо випадок, коли довготривалий запит випадково вводиться в наш додаток. База даних зазвичай обробляє лише короткочасні запити (10 мс або менше), і раптом ми отримуємо новий запит, який займає 1000 мс за кожне виконання. Це не лише забирає ресурси, а й різко збільшує кількість одночасних транзакцій. Ми або досягаємо обмежень з'єднання, або обмеження txn, або використовуємо 100% процесора бази даних / iops. Тепер розглянемо той самий сценарій, але ми встановлюємо тайм-аут 250 мс на кожній транзакції (на стороні бази даних), з експоненціальною логікою повторної спроби назад + джитером (на стороні додатка). Тепер ми обмежили радіус вибуху будь-якого окремого запиту. Довготривалі запити будуть знищені, а логіка відступу мінімізує ризик грізного зграю. Відстежуючи ці тайм-аути, ми можемо швидко виявити проблемний запит і відкотити зміни.

Журнал запису наперед (WAL) — це як швидке затвердження даних, так і безпечне відновлення після збоїв. Окрім B-дерев, це, мабуть, найважливіша структура в Postgres і MySQL. (у MySQL-land це називається «журнал повторів»)