O essencial cheatsheet de engenharia AWS: EC2 → servidores Lambda → servidores falsos EBS → discos rígidos S3 → discos rígidos lentos VPC → cosplay de LAN IAM → permissão negada CloudWatch → "temos datadog em casa"

Nunca execute consultas sem um tempo limite. Uma única consulta rebelde ou um pico de carga pode levar a paragens ou tempo de inatividade da aplicação sem elas. Vamos pensar sobre o porquê. Considere o caso em que uma consulta de longa duração é inadvertidamente introduzida na nossa aplicação. O banco de dados normalmente processa apenas consultas de curta duração (10ms ou menos) e, de repente, temos uma nova consulta que leva 1000ms por execução. Não só isso consumirá recursos, mas também aumentará o número de transações simultâneas. Vamos atingir os limites de conexão, limites de transação ou usar 100% da CPU / IOPS do banco de dados. Agora considere o mesmo cenário, mas colocamos um tempo limite de 250ms em cada transação (lado do banco de dados), com lógica de repetição de retrocesso exponencial + jitter (lado da aplicação). Agora limitamos o raio de impacto de qualquer consulta única. Consultas de longa duração serão encerradas, e a lógica de retrocesso minimiza o risco de rebanhos trovejantes. Ao monitorar esses tempos limites, podemos identificar rapidamente a consulta problemática e reverter a alteração.

O log de escrita antecipada (WAL) é tanto a forma como os bancos de dados realizam commits rapidamente quanto a forma como se recuperam de falhas de forma segura. Fora das B-trees, é provavelmente a estrutura mais importante no Postgres e no MySQL. (é chamado de "redo log" no mundo do MySQL)