Yape challenge Jonatan Pozo

[jomapozo]

Se adjunta el diagrama de arquitectura para dar contexto de cómo interactúan los distintos componentes de la solución: API, proceso antifraude, Kafka y base de datos.
La solución sigue un enfoque basado en CQRS y Event Sourcing:
Se utilizan dos tablas principales:

• Tabla Write (transaction_event_source): actúa como event store, donde se registran los eventos versionados de cada transacción.
• Tabla Read (transactions): optimizada para consultas y utilizada por la API para obtener el estado actual de la transacción.

En el docker-compose:
Se habilitó la creación automática de tópicos en Kafka únicamente para facilitar las pruebas locales.
Se incluyó un script de inicialización (init.sql) que crea las tablas necesarias cuando se levanta la base de datos.

Request para creación transacción:
http://localhost:8080/transactions
{
"accountExternalIdDebit":"878870088",
"accountExternalIdCredit":"110999098",
"transferTypeId": 1,
"amount": 1001
}
Response creación transacción:
{
"transactionExternalId": "ae16ab60-8d1d-4427-8ef6-c4370cef6a9c",
"transactionName": "TRANSFERENCIA",
"createdAt": "2026-03-05T22:12:15.643724800Z"
}

Request para consulta de transacciones:
http://localhost:8080/transactions/ae16ab60-8d1d-4427-8ef6-c4370cef6a9c

Response para consulta de transacciones:
{
"transactionExternalId": "ae16ab60-8d1d-4427-8ef6-c4370cef6a9c",
"accountExternalIdDebit": "878870088",
"accountExternalIdCredit": "110999098",
"transactionName": "TRANSFERENCIA",
"amount": 1001.00,
"transactionStatus": "RECHAZADO",
"createdAt": "2026-03-05T22:12:15.643725Z"
}