Challenge/franklinbarrios

[fbarrioss]

Presentación de Resultados: Code Challenge — Franklin Barrios Sanchez

He completado todos los 3 retos, sé que sólo se requería de uno pero me ha parecido interesante los otros dos retos y los realicé también . Cada uno de ellos se encuentra debidamente separado y organizado en su respectiva carpeta (challenge-1, challenge-2 y challenge-3) para facilitar su revisión técnica y ejecución independiente.

1. ¿Qué challenge elegí para profundizar y por qué?

Aunque completé los tres, me enfoqué en el Challenge 1 (Pipeline de Liquidación de Pagos) como pieza central de arquitectura distribuida. Lo elegí porque me permite demostrar el manejo de garantías críticas en sistemas de pagos: consistencia eventual, tolerancia a fallos y el manejo de flujos asíncronos complejos donde un error de "doble gasto" o "mensaje perdido" no es una opción.

2. Decisiones Arquitecturales Clave y Alternativas Rechazadas

• Transactional Outbox Pattern: Implementé este patrón para asegurar la atomicidad entre la base de datos y Kafka.
  • Alternativa Rechazada: Rechacé emitir mensajes directamente a Kafka desde el servicio de la API (2-Phase Commit informal). Aunque es más rápido de programar, es frágil ante caídas del broker. Con Outbox y un Relay independiente, la entrega está garantizada.
• Orquestación de Saga con Idempotencia Granular: El SagaConsumer coordina el estado final basándose en eventos de Fraude y Ledger. Utilicé claves de idempotencia compuestas (eventId + consumer_name) para que el sistema sea inmune a la duplicidad de mensajes de Kafka.
• Namespacing Geográfico: Implementé tópicos con prefijos por país (pe., mx., co.). Esto permite un aislamiento total; un problema en el pipeline de un país no afecta el procesamiento de los demás.
• Contenedorización Plug & Play: Creé un entorno completo de Docker que orquesta no solo la infraestructura (Kafka, PG), sino también los microservicios de la aplicación, haciéndolo 100% reproducible.

3. ¿Qué haría diferente con más tiempo?

• Observabilidad y Trazabilidad: Integraría OpenTelemetry para rastrear el ciclo de vida de un pago desde que entra al API hasta que es liquidado por la Saga en un dashboard visual.
• Secret Management: Migraría las API Keys de Brevo y credenciales sensibles de archivos .env a un gestor de secretos profesional (como AWS Secrets Manager).
• Pruebas de Estrés: Realizaría pruebas de carga con volumen masivo para ajustar los parámetros de concurrencia del consumidor Kafka.

4. Limitaciones Conocidas y Atajos Tomados

• Base de Datos Unificada: En un escenario real de microservicios, cada dominio (Fraude, Ledger) tendría su propio esquema o base de datos. Aquí comparten la misma instancia de Postgres por simplicidad del despliegue del challenge.
• Retry Policy Estándar: Implementé reintentos y DLT, pero una versión de producción utilizaría Exponential Backoff con Jitter para proteger los servicios ante recuperaciones de caídas masivas.