39 errores que hace(mos) al hacer scalling

Hace un tiempo que estoy suscripta al Newsletter de Neo Kim, llamado @systemdesignone, donde envia newsletters (gratuitos) con buena info, y tambien ofrece un tier de suscripcion si quieren pagar por articulos mas completos o mas especificos.

Este fin de año, mando uno muy interesante comentando los 39 (si, que numero mas raro) errores que se cometen al tratar de escalar un sistema existente. Les dejo la lista y si tienen ganas, comenten si les parece que falta alguno

1. Escalar verticalmente en vez de horizontalmente (y obviamente llegar a los limites de "no puedo agregar mas hardware")
2. Agregar "microservicios" demasiado pronto (le agregas complejidad)
3. Ignorar los load balancers
4. No usar cache, y obviamente, hacer que las consultas cada vez tarden mas de forma lineal.
5. Cachear absolutamente TODO sin ningun sentido (data desactualizada, memoria por las nubes, complejidad)
6. Olvidarse de usar CDN para los archivos estaticos
7. Mantener el server STATEFUL (y mantener la escalabilidad horizontal + complicar el recovery) -- nada de guardar las sesiones en memoria!
8. Escalar los servers antes de la parte de datos (usualmente, la base de datos es el primer cuello de botella)
9. Tratar la base de datos como "storage infinito"
10. No usar read replicas
11. Hacer sharding ANTES de entender como son los patrones de acceso
12. No usar indices en las queries criticas
13. Permitir que queries LENTAS lleguen a produccion... y obviamente hacer que todo se arrastre cuando los usuarios empiecen a crecer
14. Bloquear requests con procesamiento sincronico (async is your friend)
15. No usar Queues para background jobs
16. Ignorar los reintentos y back-off... hay que acostumbrarse a que las fallas "temporales" son naturales en sistemas distribuidos
17. No setear timeouts (y nos quedamos sin threads, y se hace un efectos cascada que tira procesos enteros abajo)
18. No setear RATE LIMITS
19. Permitir las fallas en "cascada" por no usar patrones de circuit breakers
20. Ignorar las presiones que puedan efectuar unos procesos sobre otros
21. Hacer deploy a una sola region o zona (y si se te cae us-east-1, a llorar a la iglesia)
22. No usar routeo de trafico global
23. Escalar manualmente en vez de usar auto-scalling (y actuar en base a "a ver como viene la mano, agreguemos 3 servers")
24. Lanzar los productos sin hacer tests de carga
25. Nunca hacer capacity planning
26. Guardar archivos grandes en la base de datos en vez de usar object storage como S3
27. Enviar payloads sin comprimir
28. Hacer DEMASIADAS llamadas a distintas APIs
29. No usar batching para escribir los registros
30. No usar 'service discovery'
31. No tener una estrategia de failover
32. No preparar nuestro sistema para permitir una "degradacion" parcial, si una API no contesta, se rompe todo
33. Reintentos sin idempotencia (reintentar la misma llamada a la API genera corrupcion de datos; cada llamada deberia poder reintentarse sin corromper los datos)
34. No tener observabilidad... no se puede escalar lo que no se puede medir
35. No tener alertas de monitoreo
36. No tener "tracing" a traves de servicios en un sistema distribuido
37. Escalar las cosas sin antes arreglar los cuellos de botella
38. Copiar architecturas gigantescas como esperando que eso solucione nuestros problemas
39. Creer que escalar es sobre las herramientas... y no sobre las elecciones que hacemos y las cosas que compensamos

Les parece que falta alguna? Que agregarian uds?