Plataforma de Ingesta de Datos de Mercado

¿Qué es?

Una plataforma multi-repo que ingiere un feed FIX de datos de mercado de alto volumen y mantiene dos propiedades verdaderas a la vez: la ruta nunca deja que una sesión upstream ruidosa agote la capacidad compartida, y todo mensaje que pasó por ella puede reconstruirse después. Compone dos servicios independientes. El limitador de tasa distribuido se ubica en el borde de ingesta como una puerta de admisión compartida; la sesión FIX escribe sus frames crudos a disco, y fixlog vuelve a leer esos logs sin cargarlos en RAM para responder “qué pasó realmente” durante un incidente. Cada servicio conserva su propio repositorio, sus propias pruebas y su propia página: la plataforma es el contrato entre ellos, no un monorepo que los absorbe.

Flujo entre servicios

Un frame llega por la sesión FIX y el worker de ingesta pide al limitador una decisión de admisión usando SenderCompID como clave en lugar de la IP de origen, de modo que una sola contraparte que se porta mal no pueda dejar sin recursos a las demás que comparten la misma ventana. El limitador evalúa una ventana deslizante en Redis —el mismo primitivo Allow que llama cada instancia de worker—, por lo que escalar horizontalmente el nivel de ingesta no afloja el techo global. Los frames admitidos se agregan al log de sesión FIX en disco en su forma cruda de cable y se reenvían a los consumidores downstream; los frames rechazados se descartan en el borde y se cuentan, nunca se pierden en silencio. El log de sesión es la costura entre los dos servicios: el limitador gobierna la admisión en tiempo real, mientras que fixlog opera offline sobre los bytes que el worker ya escribió, así la ruta de auditoría suma cero latencia a la ingesta.

Manejo de fallas y recuperación

Los dos dominios de falla están desacoplados a propósito. Si Redis es inalcanzable, el limitador falla cerrado para el contador global pero abierto para la liveness: cada worker recurre a una ventana local conservadora por instancia, así la ingesta sigue fluyendo a una tasa reducida y acotada en vez de detenerse ante una dependencia, y la brecha se loguea para reconciliación cuando Redis vuelve. Si un worker de ingesta se cae a mitad de una escritura, el log de sesión puede contener un frame final truncado —que es exactamente la entrada sucia que fixlog está construido para tolerar—: arrastra el frame parcial entre lecturas y lo vuelve a escanear en la siguiente pasada en lugar de tratar el truncamiento como fatal. La recuperación tras un incidente es por lo tanto una operación de solo lectura: un operador apunta fixlog a los logs de sesión rotados, filtra por SenderCompID y tipo de mensaje, y reconstruye la línea de tiempo de admitidos/descartados sin tocar la ruta viva ni repetir carga contra el limitador.

Por qué un sistema y no un proyecto

Cualquiera de los dos repositorios se sostiene solo: el limitador de tasa protege cualquier servicio Go escalado horizontalmente, y fixlog lee cualquier log FIX sin importar quién lo produjo. Lo que esta página captura es la decisión de componerlos: la elección de clave (SenderCompID, no la IP), el contrato de contador-cerrado / liveness-abierta, y el log en disco como costura compartida entre una puerta en tiempo real y un auditor offline. Esa composición es la arquitectura; los proyectos miembro conservan sus propias páginas de detalle, y esta entrada los enlaza por translationKey para que cada repositorio siga siendo la única fuente de verdad de sus propios internos.