Pipelines de eventos, rate limits y salud de servicios con modos de fallo honestos. Cuando una dependencia se cae, el que llama sabe exactamente dónde está. Estudio personal del problema de telemetría de Open Gateway. No es código de Telefónica. No es tráfico de producción.
~90ADAPTADORES EN LA LISTA DE VIGILANCIA
4PAÍSES QUE REPORTAN
3×DOWN → 1ALERTA POR EPISODIO, FIJADA POR TESTS
100%INSERCIONES IDEMPOTENTES EN EL HUB
Diagramas del sistema
FIG. 1 — PIPELINE KAFKA: gateway → Kafka → hub → Oracle, con un dashboard SSE en vivo conectado al hub.FIG. 2 — TOKEN BUCKET: cada decisión de cuota es una operación atómica; si Redis se cae, responde el fallback local.
La demo de 45 segundos
3×DOWN → 1 alert. Personal study of the Open Gateway telemetry problem — not Telefónica code, not production traffic.
El trabajo de la planta
F22026
Kafka Adapter Telemetry
Telemetría de adaptadores dirigida por eventos: pipeline Kafka gateway + hub con persistencia idempotente en Oracle, salud por adaptador, alertas y dashboard de misión en vivo vía SSE.
El problema. Una flota de ~90 adaptadores de API en 4 países necesita visibilidad operativa: quién está DOWN, desde cuándo y qué ha alertado ya. Construido como estudio personal del problema de telemetría de Open Gateway, de punta a punta.
Puntos clave
Hexagonal por servicio: el gateway publica perfiles de tránsito (low/moderate/high/overload), el hub persiste de forma idempotente por event id.
Regla de alerta fijada por tests: 3 DOWN consecutivos → exactamente 1 alerta por episodio.
DLT con reintentos absorbe duplicados y JSON corrupto sin bloquear el carril.
demo.sh demuestra el ciclo completo desde cero: recuentos idempotentes, una alerta, enrutado a DLT.
10/10 tareas entregadas con Spec-Driven Development; 3 ADRs; diagramas publicados automáticamente en GitHub Pages por CI.
Toolkit de rate-limiting para gateways de LLM: cuotas token-bucket atómicas, stores conectables y modos de fallo honestos — con una demo de gateway en Javalin que expone un endpoint estilo OpenAI.
El problema. La inferencia de LLM es cara: tráfico sin límites es un DoS a tu propia cartera. La mayoría de limitadores sufren race conditions con concurrencia o fallan en seco cuando lo hace Redis.
Puntos clave
Cada decisión de cuota se calcula de forma atómica — nunca un read-modify-write que cuele un token por encima del límite.
Ante fallo de Redis: fallback local elegante + métricas ruidosas, no 5xx masivos.
Suite de tests de contrato compartida por las implementaciones in-memory y Redis, más tests de concurrencia y de paridad.
Cabeceras X-RateLimit-* estándar y 429 + Retry-After correctos.