Challenge 1 - Camilo Medina S.

[xavi13a]

1. Elegí el Challenge 1: Payment settlement pipeline porque permite demostrar diseño distribuido con un enfoque basado en eventos y trabajar con foco en la confiabilidad operativa, aplicando conceptos como: transactional outbox, relay separado, consumidores idempotentes y DLT.

2. Decisiones arquitectónicas y alternativas rechazadas:
   Decisiones tomadas

• Transactional outbox en la API de pagos: payments + outbox_events se persisten en una sola transacción local.

• Relay como proceso separado (outbox-relay): publica a Kafka fuera de la transacción SQL.

• Idempotencia del lado consumidor por eventId usando processed_events con PK compuesta (consumerName, eventId).

• DLT explícito: al agotar reintentos, se publica payment.failed.v1 y se marca el pago como failed.

Alternativas rechazadas

• Publicar Kafka dentro de la transacción de DB.

• Agregar complejidad no requerida para el challenge: Debezium, Temporal, Redis, múltiples bases, Confluent Cloud.

• Resolver duplicación solo en broker/producer (se priorizó idempotencia en consumer, como pide el reto).

3. Que haría diferente:

• Repositorios independientes para cada componente

• Outbox también para eventos downstream (payment.settled.v1 y payment.failed.v1) para continuar con la confiabilidad operativa.

• Observabilidad más completa (métricas, tracing y dashboards).

• Seguir el marco BIAN para nombrar los componentes

4. Limitaciones:

• Se usa una sola base PostgreSQL para simplificar el challenge.

• Publicación de payment.settled.v1 / payment.failed.v1 desde workers sin outbox, ni relay.

• Topología local de Kafka de un solo broker (válida para desarrollo).

• Namespace por país no implementado en core; quedó como mejora futura.