// Caso · Sistemas de alto rendimiento
Plataforma de marketplace automatizado
Un sistema en producción que maneja dinero a escala: múltiples microservicios, pagos resilientes, un motor de matching en tiempo real y optimización combinatoria. Diseñado, construido y operado de punta a punta.
De la base de datos al firewall
Una plataforma de marketplace completamente automatizada: varios microservicios coordinados, una pasarela de pagos, ingesta de datos en tiempo real, automatización de procesos a escala y un motor de matching propio — todo en producción, manejando dinero y operando de forma desatendida.
No fue escribir features sueltas: diseñé la arquitectura, optimicé el rendimiento, blindé la seguridad y mantuve todo corriendo. Cuando algo falla a las 3 AM, sé si es el algoritmo, la base de datos, la red o un proveedor externo — y lo arreglo.
Los números
Cuatro problemas difíciles, resueltos
Cada uno es un sistema en sí mismo. Problema real, solución técnica, impacto medible.
Motor de matching en tiempo real
Conectar oferta y demanda de forma automática, ejecutando transacciones de varios pasos que pueden fallar a la mitad — sin perder consistencia ni dinero.
Motor event-driven con matching sobre Redis pub/sub, una máquina de estados por transacción y recovery multinivel: cualquier crash, error externo o interrupción se reanuda desde donde quedó. El algoritmo de selección optimiza bajo restricciones reales (presupuesto, disponibilidad, límites operativos).
Transacciones que se completan solas, se autorrecuperan ante fallos y respetan los límites de negocio. Cero intervención manual en el flujo normal.
Sistema de pagos resiliente
Los webhooks de la pasarela empezaron a fallar y se perdían órdenes ya pagadas pero no entregadas.
Diagnostiqué la caída, hice reverse-engineering de la API de pagos (sin documentación) y desarrollé un cron de reconciliación idempotente que cruza pagos aprobados contra órdenes entregadas y recupera cualquier diferencia. Sumé validación de montos (anti-fraude) y firmas HMAC en toda la comunicación servidor-a-servidor.
Cero pérdida de órdenes, aún cuando la pasarela se cae. El dinero siempre se reconcilia.
Solver de optimización con restricciones
Encontrar, entre millones de combinaciones, la opción más barata que cumpla un set de restricciones simultáneas y cruzadas.
Un solver de optimización combinatoria (tipo knapsack / CSP) que minimiza costo respetando múltiples restricciones a la vez, devolviendo el resultado en milisegundos.
Decisiones óptimas en milisegundos, donde el cálculo manual era directamente inviable.
Respuesta a DDoS y hardening
El servidor recibió un flood UDP de 26 Gbps en plena operación.
Analicé el vector de ataque, endurecí el firewall (cerré accesos administrativos expuestos a internet con reglas persistentes), apagué servicios innecesarios y preparé la migración a CDN con ocultamiento de origen.
Superficie de ataque drásticamente reducida y un plan de mitigación claro a nivel de red.
Cómo encaja todo
Servicios coordinados detrás de un edge endurecido. Redis como bus de eventos y colas; PostgreSQL como fuente de verdad.
flowchart LR
subgraph client["Cliente"]
WEB["Web app · React · Next.js"]
end
subgraph edge["Edge & seguridad"]
CF["Cloudflare / CDN"]
NG["nginx · TLS"]
end
subgraph core["Servicios core"]
API["API · Node · Express · Socket.IO"]
MATCH["Motor de matching · Node · TS"]
PAY["Pagos · webhooks · HMAC · reconciliación"]
SOLVE["Solver · Python · CSP / knapsack"]
AUTO["Automatización · Python + Go"]
INGEST["Ingesta de datos · Python"]
end
subgraph data["Datos"]
PG[("PostgreSQL")]
RD[("Redis · pub/sub + colas")]
end
subgraph ext["Externos"]
PROV["Pasarela de pagos"]
SRC["Fuentes externas"]
PLAT["Plataforma externa"]
end
WEB --> CF --> NG --> API
API --> MATCH
API --> PAY
API --> SOLVE
MATCH <--> RD
MATCH --> PG
MATCH --> SOLVE
PAY <--> PROV
PAY --> PG
INGEST --> SRC
INGEST --> RD
AUTO <--> PLAT
AUTO --> RD
SOLVE --> PG
classDef store fill:#0B0E14,stroke:#2D5BFF,color:#fff;
classDef extn fill:#FFFFFF,stroke:#8A93A3,color:#14181F;
class PG,RD store;
class PROV,SRC,PLAT extn;
// Vista de sistema — anonimizada.
sequenceDiagram
autonumber
participant C as Cliente
participant PROV as Pasarela
participant WH as Webhook
participant S as settlePayment()
participant DB as PostgreSQL
participant CRON as reconcile() cron
C->>PROV: paga
PROV-->>WH: webhook firmado (HMAC)
WH->>S: settle(paymentId)
S->>PROV: re-lee el pago (fuente de verdad)
S->>DB: entrega 1 sola vez (idempotente)
Note over PROV,WH: el webhook se pierde (outage / deploy)
CRON->>PROV: lista pagos aprobados
CRON->>S: settle(paymentId)
S->>DB: recupera las no entregadas
Note over S,DB: misma settlePayment() entonces 0 doble-entregas
// Pagos: webhook (camino rápido) + reconciliación (backstop) — la misma función idempotente para ambos.
Probalo vos mismo
Pagá órdenes, cortá el webhook a mitad de camino y corré la reconciliación. Ninguna orden pagada se pierde — y correr el reconciliador dos veces nunca duplica una entrega. (Lógica real del sistema, corriendo en tu navegador.)
| Orden | Monto | Estado | Liquidada por |
|---|---|---|---|
| Sin órdenes todavía — tocá “Pagar orden”. | |||
// Versión completa (HMAC + replay protection, tests, deploy) en el repo del demo.
Con qué está construido
Además: pipelines de datos en tiempo real, automatización de procesos a escala e integración de IA (LLMs).
Lenguajes & backend
- TypeScript / Node.js
- Python · FastAPI
- Go
- Express · Knex
- pub/sub · jobs / crons
Datos & frontend
- PostgreSQL
- Redis
- React · Next.js
- Socket.IO (tiempo real)
Infra & seguridad
- Docker
- nginx
- Cloudflare · CDN
- Tailscale
- Linux · hardening