Qué resuelve
El proveedor entrega archivos crudos cada quince minutos, con un esquema declarado que puede cambiar y sin acuerdo de nivel de servicio. Un consumidor regulado requiere el consumo por línea reconciliado contra el origen, con procedencia y sin registros perdidos.
Los datos de uso son requisito de entrada al segmento financiero: una institución regulada los necesita para control de fraude y para conciliar cargos contra su propio sistema.
Cómo funciona
Cinco capas y una verificación transversal.
- Ingesta y detección de ausencia. Un lector por perfil de entrega, huella criptográfica por archivo y descarte del duplicado. Un latido contra la cadencia esperada detecta el archivo que no llegó.
- Almacenamiento crudo. Inmutable y sólo-agregar. Es la evidencia ante una disputa y permite reprocesar desde el origen.
- Frontera de portabilidad. Copia uno a uno del archivo en formato columnar abierto, con su linaje. Una columna desconocida entra a un campo de extras y genera una migración propuesta; la ingesta continúa.
- Normalización. Decodificación, normalización de números y marcas de tiempo, deduplicación idempotente, y atribución de cliente contra un catálogo con historia. Lo que no se puede interpretar con certeza pasa a cuarentena.
- Agregados y entrega. Consumo por línea y por día, sesiones reconstruidas y libro de reconciliación. Dos salidas: archivos al almacén del cliente con manifiesto y verificación de integridad, y una API de consulta.
Cada lote emite su conteo en cada salto. Un descuadre entre dos saltos marca el lote y dispara su reproceso, sin comparación manual.
Lo que garantiza
Cinco compromisos medibles.
| Métrica | Compromiso |
|---|---|
| Disponibilidad | 99.5% mensual |
| Latencia propia | p95 menor a 10 minutos desde que aterriza el archivo |
| Completitud | 100% procesado o apartado explícitamente |
| Intervención humana | Menos de una por semana en estado estable |
| Frescura del origen | Se expone como dato; no se garantiza, depende del proveedor |
Operación sin vigilancia diaria
Seis escenarios de falla son criterios de cierre y se ensayan como simulacros: cambio de esquema en el origen, evento anterior a la sincronización de su catálogo, descuadre de conteos entre capas, archivo no entregado, caída del nodo primario de base de datos, y destino de exportación inalcanzable. El sistema debe superar los seis sin intervención.
Ese trabajo representa entre 3 y 4 semanas distribuidas a lo largo del plan. Sin él, el sistema requiere atención diaria durante toda su operación.
Volumen que tiene que soportar
Dos escenarios separados por un factor de diez. Cerrar esa diferencia es objeto de la fase 0, y es la razón de que el dimensionamiento no se fije antes.
| Escenario probable | Escenario conservador | |
|---|---|---|
| Líneas al mes 12 | 10,000 | 10,000 |
| Renglones por día | 493,000 | 4.93 millones |
| Renglones al año | 180 millones | 1,800 millones |
| Almacenamiento crudo | 145 MB por día · 52 GB al año | 1.45 GB por día · 520 GB al año |
El motor de base de datos se decide con la medición: se arranca sobre una base relacional particionada y existe un umbral declarado a partir del cual se migra a un motor columnar. La frontera de portabilidad de la capa cruda acota el alcance de esa migración.
Decisiones de diseño
El archivo de muestra se analizó antes de definir la arquitectura: siete hallazgos cuantificados y reproducibles. No se detallan aquí porque describen la calidad del insumo de un tercero; sí se detalla lo que determinaron.
- Cuarentena en lugar de inferencia. Una cifra que no se puede determinar con certeza no se estima: se aparta con su motivo registrado. Un contador nulo se trata como desconocido y no como cero, porque tratarlo como cero subestima el consumo sin dejar rastro.
- Atribución de cliente contra un catálogo con historia. Una de las familias de registro no trae identificador de cliente. La atribución responde de quién era el número en el instante del evento, no de quién es hoy. Sin eso, una línea que cambia de titular expone datos de un cliente a otro.
- Decisión de motor diferida a la medición. No se provisiona capacidad para el escenario conservador antes de saber si aplica, ni se adopta un motor especializado que complica la operación desde el arranque.
Requerimientos de infraestructura
Tres computadoras al arranque: dos en nube y una propia. La base de datos, el almacenamiento y el balanceo son servicios gestionados: no se compran ni se administran, y por eso no cuentan como computadoras.
| Dónde | Qué | Computadoras | Requerimiento |
|---|---|---|---|
| Nube | Producción · aplicación | 2 | 2 vCPU y 8 GB cada una, detrás del balanceador |
| Equipo propio | Preproducción, desarrollo e integración continua | 1 | Una sola computadora para los tres. 12 vCPU, 48 GB de memoria y 1.5 TB de disco rápido asignables |
| Nube | Producción · base de datos | servicio | PostgreSQL gestionado de 4 GiB, con réplica en espera y relevo automático |
| Nube | Producción · almacenamiento | servicio | Object storage compatible con S3, con versionado activo |
| Nube | Producción · red | servicio | Balanceador con terminación TLS y red privada cifrada |
| Total al arranque | 3 |
Aparte del conteo, y sólo si el volumen cruza el umbral: dos computadoras más en nube para el motor columnar, de 8 vCPU y 32 GB cada una, replicadas. No se provisionan al arranque, no entran en las tres, y la decisión de provisionarlas se toma con la medición de la fase 3 en la mano.
Ninguna base de datos queda expuesta a internet. La promoción entre ambientes se dispara por etiqueta en el repositorio y ejecuta la batería completa de pruebas; las de aislamiento entre clientes son bloqueantes.
El almacenamiento de objetos de los ambientes propios usa una implementación de licencia AGPL, y por eso no se usa en producción: allá se consume un servicio gestionado. Es una decisión de licenciamiento tomada por adelantado, para no abrirla durante una auditoría del cliente.
La computadora propia
Es una sola, es nueva, y es la única compra de equipo del proyecto entero. Sostiene los tres ambientes que no van en nube: preproducción, desarrollo e integración continua.
- Lo que tiene que dar: 12 vCPU, 48 GB de memoria y 1.5 TB de disco rápido asignables entre los tres ambientes.
- Configuración de referencia: 16 núcleos, 128 GB de memoria, 2 × 2 TB NVMe en RAID1 y 8 TB de disco para respaldo local. Más UPS y switch gestionado si no existen.
- Hoy el desarrollo corre sobre un NUC existente, como infraestructura provisional mientras se negocia esta computadora. Preproducción no cabe ahí: pide 32 GB de memoria y 1 TB de disco rápido que ese equipo no tiene, y además ya sostiene servicios en producción.
Producción no va sobre esta computadora, y no es preferencia. Una sola máquina sin réplica, sin redundancia de energía más allá del UPS y con el respaldo en el mismo edificio incumple el compromiso de disponibilidad y el de mínima intervención, y es difícil de sostener ante la auditoría de riesgo tecnológico de una institución regulada. Si se requiere residencia nacional de los datos, la alternativa defendible es colocación en un centro de datos mexicano certificado.
Alternativa sin compra: preproducción también en nube, encendida sólo cuando se usa. Serían tres computadoras en nube y ninguna propia, a cambio de gasto recurrente en lugar de una adquisición única.
Lo que se decide del lado de la organización
Cuatro decisiones fuera del alcance del equipo de desarrollo.
- Residencia de los datos y alcance de la capacidad de equipo propio. Determina qué corre en nube y qué no.
- Firma del contrato de interfaz con el proveedor de los datos, una vez redactado.
- Contratación de la revisión de seguridad externa, que se ejecuta en la última fase y cuyos hallazgos se remedian antes del cierre.
- Autorización del arranque de la fase 0, que es lo único que hoy mantiene el cronograma detenido.
Tiempos
24 semanas comprometidas, con 4 de contingencia declarada y techo de 28. La contingencia se consume únicamente por causas identificadas, y cada consumo se reporta. Las semanas se cuentan desde el cierre de la fase 0, que todavía no ocurre.
| Semana | Hito | Cómo se verifica |
|---|---|---|
| 4 | Contrato de interfaz cerrado | Documento firmado. Volumen medido sobre 24 horas continuas reales |
| 7 | Ingesta autónoma | Se coloca un archivo y queda registrado y almacenado en menos de 15 minutos. Se coloca dos veces y el segundo se descarta. Se dejan de colocar y el sistema lo detecta |
| 10 | Primera demostración funcional | Consumo por número y rango, reconciliado renglón por renglón contra el archivo de origen |
| 14 | Registros de sesión completos | Las tres familias normalizadas. Cuarentena en cero para un lote válido. Decisión de motor documentada con su medición |
| 17 | Entrega automática | Entrega con manifiesto que el cliente valida, y reintento automático ante fallo del destino |
| 19 | API en ambiente de pruebas | El cliente consume desde su propio código |
| 24 | Producción auditable | Los seis simulacros se superan sin intervención. Carpeta de evidencias completa |
La fase 1 arranca en la semana 3, en paralelo con la fase 0, sobre los datos de muestra disponibles. Las siete fases corren en un solo frente secuencial. El cronograma no se comprime con más capacidad de desarrollo: la fase 0 depende de respuestas de un tercero, y cada semana de demora corre el proyecto una semana.