Minuta técnica

Qué es Ferguson

Qué resuelve, qué garantiza y qué requiere

Ferguson recibe los archivos de uso de red que entrega el proveedor de conectividad, los normaliza, los verifica y los entrega al cliente final por archivo y por API. Opera entre un formato de origen que puede cambiar sin aviso y un consumidor que requiere cifras auditables. Es multi-cliente desde el primer día.

Ver el estado y el avance en vivo

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étricaCompromiso
Disponibilidad99.5% mensual
Latencia propiap95 menor a 10 minutos desde que aterriza el archivo
Completitud100% procesado o apartado explícitamente
Intervención humanaMenos de una por semana en estado estable
Frescura del origenSe 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 probableEscenario conservador
Líneas al mes 1210,00010,000
Renglones por día493,0004.93 millones
Renglones al año180 millones1,800 millones
Almacenamiento crudo145 MB por día · 52 GB al año1.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óndeQuéComputadorasRequerimiento
NubeProducción · aplicación22 vCPU y 8 GB cada una, detrás del balanceador
Equipo propioPreproducción, desarrollo e integración continua1Una sola computadora para los tres. 12 vCPU, 48 GB de memoria y 1.5 TB de disco rápido asignables
NubeProducción · base de datosservicioPostgreSQL gestionado de 4 GiB, con réplica en espera y relevo automático
NubeProducción · almacenamientoservicioObject storage compatible con S3, con versionado activo
NubeProducción · redservicioBalanceador con terminación TLS y red privada cifrada
Total al arranque3

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.

SemanaHitoCómo se verifica
4Contrato de interfaz cerradoDocumento firmado. Volumen medido sobre 24 horas continuas reales
7Ingesta autónomaSe 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
10Primera demostración funcionalConsumo por número y rango, reconciliado renglón por renglón contra el archivo de origen
14Registros de sesión completosLas tres familias normalizadas. Cuarentena en cero para un lote válido. Decisión de motor documentada con su medición
17Entrega automáticaEntrega con manifiesto que el cliente valida, y reintento automático ante fallo del destino
19API en ambiente de pruebasEl cliente consume desde su propio código
24Producción auditableLos 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.