Saber cuando una funcionalidad no merece la pena
La verdad incómoda: la mayor parte de lo que hay en este capítulo no debería publicarse. No porque los patrones estén mal —son los mismos que llevas usando desde el capítulo 2— sino porque la mayoría de las APIs nunca alcanzan la escala en la que los webhooks ganan a consultar periódicamente, en la que cincuenta dominios de golpe son una petición real, o en la que un índice de búsqueda se gana su riesgo de quedarse rancio. Construir la versión sofisticada de una funcionalidad que nadie ha pedido todavía es el mismo error que la arquitectura prematura contra la que este libro lleva argumentando desde la primera página, con un disfraz más avanzado.
Hazte tres preguntas antes de construir nada de esto:
- ¿Ha fallado de verdad la versión simple? No «¿podría fallar a escala algún día?», sino si un consumidor real se ha topado con un muro real.
- ¿Puedes medir el coste de no tenerlo? «Los consumidores consultan nuestro endpoint doscientas mil veces al día para detectar cambios que ocurren cuarenta veces al día» es un número. «Estaría bien tener webhooks» no lo es.
- ¿Estás dispuesto a operarlo? Un sistema de webhooks significa un registro de entregas que vigilar. Un endpoint por lotes significa una cola que mantener sana. Un índice de búsqueda significa una historia sobre datos rancios. Si nadie asume ese coste operativo, la funcionalidad no está terminada: es dolor aplazado.
Antes de construir:
- [X] La versión simple está en producción y ha fallado de forma medible
- [X] Puedes nombrar el coste con un número, no con una sensación
- [X] Alguien se hace cargo de vigilarlo cuando se publique
Una vez construido:
- [X] Los fallos de entrega, lote y exportación son demostrables desde una tabla, no inferidos del silencio
- [X] Cada política de reintentos distingue «esto no va a funcionar nunca» de «esto puede funcionar en treinta segundos»
- [X] Cada copia de datos tiene una fuente de verdad que gana claramente y una forma de reconstruirse desde ella
Las funcionalidades avanzadas no son donde puedes dejar de ser disciplinado. Son donde la disciplina más importa, porque son las funcionalidades sobre las que quien consume construye sus propios sistemas. Haz primero que lo básico sea aburrido. Luego haz que lo avanzado sea igual de aburrido.