Confiabilidad: fallas, rate limiting y observabilidad
No te preocupes si estas palabras suenan intimidantes: iremos explicando cada una en el camino. En esta lección aprendemos a hablar en una entrevista sobre las formas de mantener un sistema estable incluso cuando algo sale mal: timeouts (dejar de esperar una respuesta después de un tiempo determinad
El System Design (planear cómo construir software grande que atienda a muchas personas) es como planear una ciudad: calles, almacenamiento, semáforos y equipos de mantenimiento para que la ciudad siga funcionando bien incluso en hora pico, cuando todos salen a la vez.
- Confiabilidad y observabilidad
- La idea central de esta lección: cómo mantenemos el sistema confiable (siempre funcionando) y capaces de ver qué está pasando adentro. Incluye: cuándo dejar de esperar (timeouts), cuándo intentar de nuevo (retries), cuándo bloquear temporalmente para evitar una caída (circuit breakers), cómo limitar cuántas solicitudes se permiten (rate limits), y cómo observar lo que pasa usando metrics, logs y tracing (seguir una solicitud).
- Trade-off
- Trade-off: una elección consciente en la que ganas algo y lo pagas con otra cosa, como elegir comida rápida en lugar de una comida casera: ahorras tiempo pero pierdes algo de calidad. En una entrevista explicas qué ganaste y qué te costó.
- Métrica operativa
- Una métrica operativa: un número que muestra si la decisión realmente funciona cuando el sistema está en vivo y atendiendo usuarios reales (esto se llama producción). Por ejemplo: latency (cuánto tarda en llegar una respuesta), error rate (la proporción de solicitudes que fallan), queue lag (cuántas tareas están esperando en fila), cache hit ratio (con qué frecuencia encontramos la respuesta en memoria rápida), y más.