El valle de los webhooks: por qué replicar datos vía notificaciones siempre falla

Quien firma este artículo ha montado el mismo sistema de integración con webhooks en tres empresas distintas y el resultado fue idéntico: una pila de parches que intenta reconstruir, a partir de notificaciones HTTP, una copia local fiel del estado que vive en el proveedor (Stripe, un IdP, una plataforma de email). La primera vez parecía un endpoint; al final eran firmas, deduplicación, buffering por orden de eventos, importador inicial y un cron de reconciliación nocturna que asume que la copia local puede divergir sin aviso. Los webhooks nacieron en 2007 (el término lo acuñó Jeff Lindsay) para disparar efectos colaterales: lanzar un build, enviar un recibo. Lo que se les pide hoy, mantener sincronizada una replica de los datos del proveedor, es un trabajo distinto que requiere orden, completitud, bootstrap y verificabilidad, justo las propiedades que los webhooks no garantizan. El texto compara la situación con un óptimo local en un paisaje de fitness evolutiva: cada workaround (Svix, Hookdeck, EventBridge, los conectores tipo Fivetran/Airbyte, los túneles locales como stripe listen) es ingeniería excelente empotrada en el fondo del valle. Los proveedores que conservan un log de eventos —Stripe expone 30 días y un endpoint /v1/events— apuntan a la solución real: tratar la replicación entre sistemas como lo que es dentro de una base de datos, replicación desde un log ordenado, y dejar de reconstruirla a base de doorbells.