Dos formatos que entran, uno solo que sale
El problema
Las agencias de noticias entregan su material —cables de texto y fotos— cada una a su manera. Una lo deja por FTP; otra usa un agente propio que baja los archivos. Los formatos no se parecen entre sí, y encima hay producción propia que tampoco calza con ninguno de los dos.
Y hay un detalle que cambia todo: los directorios de origen son efímeros. Se rotan y se borran por antigüedad. Lo que no se ingesta a tiempo, no se ingesta nunca.
Del otro lado, varios consumidores querían ese contenido: sistemas internos y también terceros fuera de la casa.
La decisión que ordenó todo
Cada formato de origen se normaliza a un único modelo canónico, agnóstico de qué agencia lo mandó. Todo lo que pasa de ese punto hacia adelante ya no sabe —ni necesita saber— de dónde vino el contenido.
Dónde termina la diferencia entre agencias
- Origen Un formato por agencia Una entrega por FTP, otra mediante su propio agente, más la producción de la casa. Tres formas distintas de decir lo mismo.
- Ingesta Modelo canónico Acá se acaba la diferencia. Un cable es un cable, venga de donde venga.
- Distribución Una sola API Los consumidores nunca ven un formato de agencia. Sumar una agencia nueva no les cambia nada.
Qué construí
Dos APIs separadas a propósito, no una con roles adentro:
- La API pública sirve cables y fotos a los consumidores. Autentica por clave de API, pagina por cursor y registra cada llamada.
- La API de administración es donde se dan de alta agencias y consumidores, se emiten y revocan claves, se mira la actividad y se consulta el estado del sistema. Vive detrás de una lista de IP permitidas.
Un proceso de fondo se ocupa de la retención: los cables, la auditoría y los eventos de salud se podan solos según su propia política.
Las decisiones que costaron
Separar la API pública de la de administración en dos aplicaciones. Podrían ser una sola con autorización por rol. Pero entonces el código que emite claves y el que las valida corren en el mismo proceso, expuesto a internet. Separarlas cuesta más infraestructura y elimina toda una familia de errores de configuración: la API pública sencillamente no tiene los endpoints de administración.
La clave se muestra una sola vez. Se guarda su huella, no la clave. Si el administrador la pierde, no hay recuperación: hay que emitir una nueva y revocar la anterior. Es incómodo a propósito — que el sistema pueda mostrarte la clave otra vez significa que la tiene guardada, y eso es exactamente lo que no queremos.
Ensayo antes de conectar. Dar de alta una agencia sin poder probarla es adivinar. Hay un modo de prueba que lee el origen y muestra qué saldría, sin escribir nada.
Salud que mira lo que puede fallar de verdad. No alcanza con responder «estoy vivo». Los chequeos miran si la base contesta, si el directorio de origen sigue montado y si la auditoría se está saturando — que son las tres formas concretas en que este sistema deja de servir aunque el proceso siga en pie.
Vista ilustrativa · datos de ejemplo
| Consumidor | Claves | Últimas 24 h | Estado |
|---|---|---|---|
| visor-interno | 2 | 14.208 | Activo |
| portal-vertical | 1 | 3.104 | Activo |
| tercero-a | 1 | 871 | Activo |
| tercero-b | 0 | — | Sin claves |
Salud
- Base de datosresponde
- Directorio de origenmontado
- Auditoría78 % de saturación
Clave generada
ak_7f3c··········9b21
Esta clave se muestra una sola vez. El sistema guarda su huella, no la clave. Si se pierde, hay que emitir una nueva y revocar esta.
CopiarYa la guardé
Resultado
El contenido de todas las agencias entra por un solo modelo y sale por una sola API, con claves por consumidor, registro de actividad y retención automática. Sumar una agencia nueva es escribir un traductor: nadie del otro lado se entera.