Corregir un acta no termina en la base: cachés y exportaciones
Corregir una fila no actualiza por sí solo respuestas cacheadas, archivos exportados ni consumidores. La rectificación necesita versión, evento y cierre verificable.
Por Marco Ferreiro ·
Cuando una fuente corrige el estado, importe o identificador de una infracción, actualizar la fila principal es sólo el comienzo. La versión anterior puede seguir en una respuesta cacheada, un índice de búsqueda, un webhook pendiente, un CSV descargado o el sistema de una empresa cliente.
La corrección de un acta se considera completa cuando todas las superficies relevantes conocen la nueva versión o declaran explícitamente que la anterior quedó superada. Ese cierre requiere identidad, orden, reintentos y evidencia.
La corrección es un hecho nuevo
No sobrescribimos silenciosamente el acta anterior. Creamos una versión con:
- identificador estable de la entidad;
- número de versión monotónico;
- campos anteriores y nuevos permitidos;
- motivo o código de rectificación;
- fuente y momento de observación;
- actor o proceso autorizado;
- trace ID y evento asociado.
El estado actual apunta a la versión más reciente, pero las anteriores permanecen disponibles según la política de retención. Así podemos explicar qué acta recibió una exportación en su fecha.
El evento debe nacer junto con la transacción
Si primero se confirma la base y después se intenta publicar un mensaje, una caída entre ambos pasos deja el acta corregida sin propagación. Un patrón de salida transaccional registra el evento en la misma confirmación que la nueva versión; un publicador lo entrega luego.
La decodificación lógica de PostgreSQL es otra infraestructura posible para extraer cambios confirmados. Su documentación advierte que, tras fallas, un consumidor puede volver a recibir cambios recientes. Por eso la entrega se diseña como al menos una vez y los efectos son idempotentes.
No suponemos una garantía exacta por el nombre de la herramienta. Probamos reinicio, duplicación y atraso.
Una identidad de evento permite deduplicar
CloudEvents define atributos como id, source, type y time; la combinación de fuente e ID permite reconocer duplicados. Para la corrección de un acta agregamos versión de esquema y versión de entidad en datos definidos por nuestro contrato.
Cada consumidor registra el último evento aplicado o, preferentemente, la última versión por entidad. Si recibe la misma versión, confirma sin repetir efectos. Si recibe una anterior, la ignora y deja auditoría. Si detecta un salto, solicita recuperación o relectura.
El ID no contiene patente, CUIT ni número de acta en claro. Es opaco y se vincula dentro de un entorno protegido.
La caché se invalida por todas las claves derivadas
Una entidad puede aparecer en detalle, listados, totales, respuestas por patente y vistas de flota. Borrar sólo la clave del detalle deja copias inconsistentes. Mantenemos un mapa de dependencias o usamos claves versionadas que cambian con la entidad o colección.
RFC 9111 describe validación, frescura e invalidación en caché HTTP. Los validadores como ETag ayudan a que un cliente compruebe si la representación cambió, pero no empujan automáticamente la rectificación a una copia que todavía considera fresca.
La estrategia combina:
- TTL acotado según riesgo;
- invalidación de claves conocidas;
- ETag derivado de la versión;
- ausencia de
immutableen recursos corregibles; - purga o revalidación del edge cuando corresponda.
Un cliente abierto debe recibir una señal o revalidar después del plazo acordado.
Los índices son consumidores, no la fuente de verdad
Un buscador o vista materializada puede actualizarse de forma asíncrona. Su documento guarda la versión del acta. El indexador sólo escribe si el evento es más nuevo que la versión almacenada.
Después, una conciliación toma una muestra o recorre el universo esperado y compara versión en base e índice. “El mensaje fue consumido” no demuestra que el documento quedó correcto; pudo fallar la escritura o mapearse un campo de forma equivocada.
Si hay una reconstrucción completa, usa un corte consistente y luego aplica los eventos posteriores al corte.
Un webhook debe describir la rectificación
El consumidor necesita distinguir un acta nueva, una actualización de la jurisdicción y una rectificación. El evento incluye tipo estable, versión, campos cambiados permitidos y referencia a la observación. No envía el registro completo si no es necesario.
Los reintentos conservan el mismo ID. La respuesta exitosa confirma recepción según el contrato, no aplicación final en el sistema ajeno. Para integraciones críticas puede existir una consulta de estado o una reconciliación por versión.
Si el endpoint estuvo caído, el evento no se pierde al vencer una memoria local; queda en una cola durable o se recupera desde el historial autorizado.
Las exportaciones no se pueden retirar de una computadora
El CSV de multas ya descargado puede seguir en uso. Sobrescribir el archivo en el servidor no cambia esas copias. Cada exportación debe incluir fecha de corte, versión de esquema, identificador y, cuando sea viable, versión máxima o snapshot.
Cuando una jurisdicción corrige un acta:
- se genera una nueva exportación;
- la anterior queda marcada como superada en el catálogo;
- se publica la relación entre ambas;
- se notifica por el canal acordado a destinatarios autorizados;
- se evita borrar la evidencia de lo que efectivamente se entregó.
Una exportación incremental puede emitir una fila con el acta corregida, pero el consumidor debe saber cómo aplicarla de forma idempotente.
La versión acompaña a cada superficie
La matriz de cierre registra:
| Superficie | Evidencia de aplicación |
|---|---|
| Base principal | Versión actual y transacción |
| Evento | ID, versión y estado de entrega |
| Caché de aplicación | Clave o generación actual |
| CDN o caché HTTP | ETag, purga o revalidación |
| Índice | Versión del documento |
| Webhook | Entrega y versión aceptada |
| Exportación | Revisión nueva y anterior superada |
El trace ID enlaza operaciones técnicas siguiendo Trace Context, sin reemplazar la identidad de evento ni la versión de negocio.
Reintentar no debe crear efectos nuevos
Probamos la misma rectificación repetida, eventos fuera de orden, salto de versión, consumidor detenido y reconstrucción de índice. También simulamos una caída después de guardar la base pero antes de publicar, y otra después de entregar pero antes de confirmar.
Los resultados esperados son: una sola versión vigente, ninguna notificación duplicada con efecto comercial, cachés eventualmente actualizadas dentro del objetivo y exportaciones relacionadas sin pérdida histórica.
Una cola vacía no es criterio suficiente. La conciliación debe verificar el estado materializado.
La privacidad también se propaga
Si la corrección quita el dato del titular, cada derivado debe dejar de exponerlo según su política. Logs, trazas y backups requieren tratamientos diferentes; no se promete una eliminación instantánea imposible.
El evento contiene sólo lo necesario para aplicar el cambio. Patentes, CUIT y payloads completos no viajan en claves de caché públicas, etiquetas métricas o IDs. Los accesos a versiones anteriores quedan restringidos y auditados.
El cierre es una afirmación comprobable
Una operación puede mostrar “actualizado” mientras la flota sigue descargando un informe de multas viejo. Por eso el estado final se obtiene de la matriz: versión esperada, versión observada, hora y excepción abierta por consumidor.
La rectificación termina cuando esa evidencia muestra convergencia o cuando cada excepción está declarada y acotada. La base es la fuente de verdad, pero la experiencia real depende de todas las copias que construimos alrededor de ella.
Metodología
- Alcance
- Propagación técnica de una corrección versionada hacia superficies derivadas con entrega repetible, consumidores idempotentes y conciliación posterior.
- Unidad de análisis
- Cada rectificación lógica y cada consumidor o artefacto que debe reflejar su versión.
- Cobertura
- Estándares HTTP, CloudEvents, Trace Context y documentación oficial de PostgreSQL revisados el 14 de agosto de 2026.
Limitaciones
- La arquitectura exacta depende de garantías transaccionales, productos de caché, retención y contratos de cada integración.
- Una propagación técnica no modifica por sí sola el expediente de la autoridad ni autoriza borrar evidencia histórica.
Fuentes
- RFC 9111 sobre caché HTTP e invalidación — RFC Editor (consultada el )
- Especificación CloudEvents versión 1.0.2 — Cloud Native Computing Foundation (consultada el )
- Documentación actual de decodificación lógica de PostgreSQL — PostgreSQL Global Development Group (consultada el )
- Conceptos de decodificación lógica y repetición de cambios — PostgreSQL Global Development Group (consultada el )
- Recomendación W3C Trace Context — World Wide Web Consortium (consultada el )
Preguntas frecuentes
¿Borrar la clave de caché alcanza para cerrar una rectificación?
No. Puede haber cachés intermedias, índices, archivos y consumidores desconectados. Cada superficie debe confirmar una versión igual o posterior a la rectificación.
¿Una exportación histórica debe sobrescribirse con los datos nuevos?
Normalmente conviene conservarla como evidencia de lo emitido y marcarla como superada, publicando una revisión nueva con relación explícita a la anterior.
¿Qué ocurre si el mismo evento de rectificación llega dos veces?
El consumidor usa un ID idempotente y la versión del registro. Reaplicar la misma versión no debe duplicar webhooks, archivos ni efectos comerciales.
Notas relacionadas
Cómo versionar una respuesta cuando cada jurisdicción cambia
Una respuesta agregada necesita distinguir versión de contrato, revisión de datos y estado de cada fuente. Así un cambio municipal no obliga a reinterpretar silenciosamente todo el resultado.
Cobertura de una API: cómo comunicar fuentes caídas y resultados parciales
Una integración de infracciones necesita informar qué fuentes respondió, cuáles fallaron y si el resultado es completo. Un cero sin cobertura comprobada puede inducir decisiones incorrectas.
Webhooks de nuevas multas: idempotencia, reintentos y trazabilidad
Un webhook confiable puede llegar más de una vez, demorarse o fallar después de ser procesado. El diseño debe deduplicar eventos, reintentar con límites y conservar evidencia de punta a punta.