Alexei Rojas Quiroga
← Todos los proyectos

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
LO QUE CONSTRUÍCheckout delcomercioEnvía solicitudes yrecibe resultadosASP.NET CoreRecepción de pagosValida y aceptasolicitudesRabbitMQCola de solicitudesAlmacena solicitudes depago.NET workerEjecutor de pagosEjecuta pagos en lacadenaBTC/ETH/LTCAdaptadores demonedasUn adaptador por monedaRPC per coinNodos blockchainRed de cada monedasoportadaRabbitMQCola de mensajesfallidosMensajes fallidos pararevisiónBilletera delusuarioFondos y firmaSQL ServerAlmacén de pagosPagos e historial deestados123
  • 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.

Stack tecnológico

Lenguajes
C#
Backend
.NETASP.NET CoreSignalR
Mensajería
RabbitMQ
Datos
SQL Server
Otros
Bitcoin, Ethereum, Litecoin nodes (RPC)