Migrar de polling a webhooks

Consultar la API cada minuto gasta límite de tasa, agrega latencia y se pierde los cambios intermedios. Los webhooks resuelven las tres cosas, pero la migración conviene hacerla en capas.

1. Escribí el consumidor en paralelo

Creá el webhook y procesá los eventos escribiendo en una tabla aparte. No toques todavía tu tabla de producción.

2. Compará durante unos días

Con el job de polling todavía activo, compará ambos resultados. Deberían coincidir salvo por los cambios intermedios, que solo ve el webhook.

-- Filas que el polling no vioSELECT w.object_id, w.updated_atFROM webhook_state wLEFT JOIN polling_state p ON p.object_id = w.object_idWHERE p.object_id IS NULL   OR p.updated_at < w.updated_at;

3. Cambiá la fuente de verdad

Cuando la comparación no muestre diferencias, apuntá tu lógica a la tabla del webhook y bajá la frecuencia del polling a una vez por día.

4. Dejá una red de seguridad

Guardá un job diario que reconcilie contra GET /v1/... con updated_after. Cubre el caso raro de una caída larga de tu endpoint.

Si tu servicio estuvo caído más de 24 horas, los reintentos ya vencieron: la reconciliación es la única forma de recuperar esos cambios.