feat: payment project for Yape

[OmarLove]

Which challenge you chose and why.
Lei los 3 proyectos y todos estan muy interesantes para resolver porque en mis 3 ultimas experiencias (Alfi, Culqi y GG) he trabajado integrando pasarelas de pago como mercadoPago y Stripe. También he participado en la implementacion de sistemas distribuidos en distintas entidades financieras en LATAM, que hacen uso de arquitecturas orientada a servicios y eventos. Escogi este ejercicio porque:

• muestra y/o demuestra el flujo de pago simple transaccionalmente hablando,
• por la implementación de patrones como el patrón outbox, ya que garantiza la operación de pago,
• porque se implementa un handler, en este caso el Dead Letter Topic,
• y porque simula una arquitectura de microservicios y eventos.

The key architectural decisions you made and the alternatives you rejected.
Decisiones de arquitectura:

• Por qué no publicar directo a Kafka?
  Porque mezclar DB y broker en la misma operación aumenta el riesgo de inconsistencias.

• Por qué no Temporal?
  Porque para este alcance, Kafka + PostgreSQL + aggregation persistida resuelven el problema central con menor complejidad.

• Por qué notify no bloquea settlement?
  Porque lo tratamos como efecto lateral no financiero.

What you would do differently with more time.

• dashboards y métricas
• integración con tracing
• particionado por país
• tests de integración más fuertes

Any known limitations or shortcuts taken.

• Los retries técnicos del ejemplo están simplificados.
• No hay tracing ni métricas.
• No hay reglas por país.