Proyecto corporativo · Presentado sin referencias a la empresa: solo arquitectura y decisiones.
Plataforma de pagos con criptomonedas
Plataforma distribuida para que comercios acepten pagos en cualquier criptomoneda
Estado
En producción
Rol
Ingeniero backend: microservicios, mensajería, notificaciones en tiempo real
Arquitectura
Bitcoin · Ethereum · Litecoin
Bus de mensajes RabbitMQ
Persistencia en SQL Server
Manejo de mensajes fallidos
El cliente del comercio envía una solicitud de pago; la API la valida y la guarda como pendiente, luego la encola y responde de inmediato.
Arquitectura · 9 nodos · 2 flujos
1Checkout del comercio → Recepción de pagossolicitud de pago
Servicio / cómputo
Almacén de datos
Cola / mensajería
Cliente
Sistema externo
Síncrono
Asíncrono / bucle
Desplázate hacia los lados para ver todo el diagrama
Cómo fluye, paso a paso
Haz clic en un paso para saltar a él. Haz clic en un componente para ver detalles.
Qué hace
Una plataforma de pagos distribuida que cualquier comercio podía integrar para aceptar pagos en Bitcoin, Ethereum, Litecoin y otras criptomonedas. Los microservicios en C#/.NET se comunican mediante RabbitMQ: uno recibe y encola solicitudes de pago, otro ejecuta el pago en la blockchain con la wallet del usuario, y un tercero espera la confirmación y entrega el resultado al cliente en tiempo real mediante SignalR. El estado vive en SQL Server.
El problema
Los comercios querían aceptar criptomonedas sin construir integraciones con blockchains, pero los pagos on-chain tardan en confirmarse y pueden fallar. La plataforma debía aceptar solicitudes de forma fiable, ejecutarlas con seguridad e informar al cliente el resultado en cuanto fuera definitivo.
Qué construí
Microservicios desacoplados por RabbitMQ: la recepción, la ejecución on-chain, el seguimiento de confirmaciones y la notificación escalan y fallan de forma independiente.
La API de pagos acepta y encola solicitudes rápidamente, de modo que el comercio recibe un acuse inmediato mientras el trabajo pesado ocurre de forma asíncrona.
Procesamiento idempotente de mensajes para que un mensaje reentregado nunca envíe dos veces el mismo pago.
Ejecución separada de confirmación: un Confirmation Watcher sigue la finalidad en la blockchain, que puede tardar minutos, sin bloquear al ejecutor.
Resultados en tiempo real entregados al cliente mediante un hub de SignalR en lugar de polling.
Los adaptadores de moneda dan a Bitcoin, Ethereum y Litecoin un contrato de ejecución común, y cada transición de estado del pago se persiste en SQL Server.
Decisiones clave y por qué
01
RabbitMQ como bus entre microservicios
Las colas absorben picos, permiten escalar cada servicio por separado y mantienen seguras las solicitudes aceptadas si un servicio posterior cae; los mensajes fallidos van a una dead-letter queue para su revisión.
02
Procesamiento idempotente
La mensajería es at-least-once, así que cada pago lleva una clave única y los handlers revisan el estado persistido antes de actuar, evitando transacciones on-chain duplicadas.
03
Separar ejecución de confirmación
Emitir una transacción es rápido, pero la finalidad es lenta y variable según la cadena. Un watcher dedicado consulta las confirmaciones y emite un evento, así los ejecutores quedan libres.
04
Push con SignalR en lugar de polling
Los clientes conocen el resultado en cuanto llega el evento de confirmación, con menos carga y menor latencia que consultas repetidas de estado.
05
SQL Server como sistema de registro
El estado del pago y su historial son relacionales y transaccionales, lo que facilita recuperación, conciliación y auditoría.