Niégate a empezar lo que no puedes terminar
Con las capacidades nombradas, la puerta es obvia: comprueba antes de empezar, no a mitad de camino.
Aprovisionar un sitio es una cadena larga —generar contenido, crear un repositorio, aprovisionar un servidor, desplegar, verificar. Si el proveedor del modelo está caído, la cadena falla en el primer paso, habiendo consumido ya un hueco, creado un registro y dado al usuario una barra de progreso que está a punto de morir.
El comportamiento correcto es declinar en la puerta: «La creación de sitios no está disponible ahora mismo. Inténtalo de nuevo en un momento.»
Es el nunca empieces un trabajo que no puedes terminar del capítulo 6, elevado de una sola llamada a un flujo entero. Una negativa clara es mejor producto que un fallo ambicioso: le cuesta al usuario diez segundos en vez de cinco minutos, y no deja nada que limpiar.
Deja de preguntarle a un servicio caído
El capítulo 1 estableció qué fallos merecen reintento: errores de conexión, 5xx y 429. Esa es la política correcta para una llamada. Es la política equivocada para la llamada número mil seguida mientras un proveedor está fuera.
Los reintentos contra un servicio realmente caído son peor que inútiles. Multiplican la carga sobre algo que ya sufre, convierten un fallo rápido en uno lento —tres intentos con esperas antes de la misma respuesta— y retienen tus workers todo ese rato.
Un cortacircuitos lo arregla recordando. Tras un umbral de fallos deja de hacer la llamada por completo y falla de inmediato; tras un periodo de enfriamiento deja pasar una para ver si el mundo ha cambiado.
La consecuencia importante no son las peticiones ahorradas. Es que el fallo se vuelve rápido, lo que significa que la cola sigue avanzando, los workers no quedan retenidos y el usuario recibe una respuesta en milisegundos en vez de un minuto de silencio.
Di qué va mal sin nombrar al proveedor
// always in Webplo's own terms, never the underlying vendor
Nunca «OpenAI está caído» ni «Stripe devolvió un 503».
En parte porque no ayuda: un comerciante no tiene relación con tus proveedores y no puede actuar sobre sus nombres. Sobre todo porque es una divulgación de arquitectura, permanentemente pública, que le dice a cualquiera que lo lea qué sondear y de qué está montado tu producto. Y envejece mal: cambia de proveedor y años de mensajes de error, capturas y artículos de soporte quedan equivocados.
Di qué no puede hacer el usuario, y cuándo volver: «Ahora mismo no se pueden crear sitios nuevos. Todo lo ya publicado no está afectado; inténtalo de nuevo en unos minutos.» Preciso sobre el alcance, honesto sobre el impacto, callado sobre las tuberías.
Lo que sostiene este capítulo
- Nombra tus dependencias como un enum, para que la salud sea un hecho que guardas y no una suposición a partir de un 502.
- Nombra las capacidades aparte, en términos de producto, y mapéalas a dependencias con un
match. - Una capacidad necesita todas sus dependencias sanas, y el mapa responde «¿qué pueden seguir haciendo los clientes?» sin una reunión.
- Cierra la puerta al principio del flujo. Una negativa clara gana a un fallo ambicioso que deja estado detrás.
- Añade un cortacircuitos encima de tu política de reintentos. Su valor es fallar rápido, no ahorrar peticiones.
- Nunca nombres al proveedor ante el usuario. No es accionable, es divulgación de arquitectura y envejece mal.