Основная шпаргалка по инженерии AWS: EC2 → серверы Lambda → фейковые серверы EBS → жесткие диски S3 → медленные жесткие диски VPC → косплей локальной сети IAM → доступ запрещен CloudWatch → "у нас есть datadog дома"

Никогда не запускайте запросы без таймаута. Один единственный злонамеренный запрос или всплеск нагрузки могут привести к зависаниям или простоям приложения без них. Давайте подумаем, почему. Представьте случай, когда в наше приложение случайно попадает долгий запрос. База данных обычно обрабатывает только краткосрочные запросы (10 мс или меньше), и вдруг у нас появляется новый запрос, который занимает 1000 мс на выполнение. Это не только будет потреблять ресурсы, но и увеличит количество одновременных транзакций. Мы либо достигнем пределов соединений, пределов транзакций, либо используем 100% процессора / IOPS базы данных. Теперь рассмотрим ту же ситуацию, но мы устанавливаем таймаут в 250 мс для каждой транзакции (на стороне базы данных), с логикой повторных попыток с экспоненциальным увеличением времени ожидания + джиттером (на стороне приложения). Мы теперь ограничили радиус поражения любого отдельного запроса. Долгие запросы будут завершены, а логика увеличения времени ожидания минимизирует риск "громовых стад". Мониторя эти таймауты, мы можем быстро идентифицировать проблемный запрос и откатить изменения.

Журнал предварительной записи (WAL) — это как базы данных быстро фиксируют изменения и как они безопасно восстанавливаются после сбоев. Помимо B-деревьев, это, вероятно, самая важная структура в Postgres и MySQL. (в MySQL это называется "журнал повторной записи")