Pulsas Enviar en una transferencia. La app muestra un spinner un segundo y listo.
Lo que no ves: enrutamiento en API gateway, autenticación, validación de saldo, movimientos contables, reglas de fraude, publicación de eventos, notificaciones, trazas de observabilidad y docenas de trade-offs que decidieron si el dinero se mueve seguro, rápido, o ambos.
Llevo años entregando backends. Aun así me pilla pensando que una fintech es "un CRUD con columna de saldo". No lo es. Esa distancia — entre lo que el usuario ve y lo que ingeniería debe acertar — es la razón de esta serie.
La chispa: el diagrama de alguien más
Emiliano Mauro López publicó un desglose de lo que hay detrás de una fintech moderna: gateway, auth, servicios core, fraude, Kafka, Redis, S3, observabilidad, AWS, cumplimiento. Nada nuevo para un backend senior — pero presentado como decisiones, no como buzzwords.
Una frase se me quedó:
La diferencia entre una fintech que escala y una que colapsa está en el diseño interno.
Ya había visto esas cajas, en fragmentos, en sistemas de producción. El post no me enseñó palabras nuevas. Me dio permiso para dejar de acumular repos y empezar a contar la historia en público.
Punto de partida: una prueba técnica contra reloj
Hace unos meses hice una prueba técnica y publiqué el resultado: arkano-banking-challenge.
Funcionaba. Entregué a tiempo. Cuentas, movimientos, la forma de una API bancaria pequeña — suficiente para la barra.
Lo que no dejé atrás fue profundidad:
- ¿Por qué este límite y no otro?
- ¿Qué pasa cuando Kafka entrega el mismo evento dos veces?
- ¿Cuándo un monolito modular es más inteligente que seis microservicios el día uno?
Desde entonces seguí construyendo backends con más exigencia — demos event-driven, starters NestJS, APIs en producción. El repo Arkano quedó como marcador: pudiste correr; ahora aprende a explicar.
Esta serie no es un fork de ese repositorio. Reconstruyo desde cero, a propósito, a un ritmo donde cada fase documenta el por qué, no solo el qué.
Qué estoy construyendo (y qué no)
fintech-core-platform (open source, por fases) es un backend de referencia:
- NestJS, TypeScript strict, límites hexagonales
- PostgreSQL transaccional
- Redpanda (API Kafka) en desarrollo local
- MiniStack para servicios AWS en dev (S3, Secrets Manager, SES)
- OpenAPI, tests, CI — una fase a la vez
Qué no es:
- Un banco con licencia, rails SPEI/ACH reales, ni AML/KYC regulatorio completo
- Un clon de cada caja del diagrama enterprise en la semana uno
- Una carrera a microservicios para capturas de LinkedIn
El objetivo es craft backend senior demostrable: trade-offs explícitos, patrones de producción (outbox, idempotencia, DLQ) y una arquitectura que evoluciona de monolito modular a servicios orientados a eventos — cuando el dominio justifica el costo.
Cómo está organizada la serie
Cada entrega combina artículo en el blog (profundidad, diagramas, laboratorio) y código open source en GitHub, fase a fase. En LinkedIn comparto un resumen con enlace al artículo completo.
Índice de la serie: makingcode.dev/series/fintech-core-platform
Roadmap (vista general)
| Fase |
Tema |
Idea |
| 0 |
Monolito modular |
Módulo Accounts hexagonal — sin microservicios prematuros |
| 1 |
Ledger y dinero |
Centavos enteros, invariantes, cero float |
| 2 |
Eventos |
Redpanda, outbox, consumidores idempotentes, DLQ |
| 3 |
Pagos |
Adapter de PSP, webhooks, saga lite |
| 4 |
Auth y límites |
JWT, RBAC, rate limit con Redis |
| 5 |
Fraude |
Reglas antes que ML |
| 6 |
Plataforma |
Notificaciones, observabilidad, recibos S3 |
| 7+ |
Gateway, KYC lite, deploy AWS |
Stretch, documentado con honestidad |
Cada fase = uno o más artículos + un post LinkedIn. No saltaré los cimientos "aburridos" — ahí viven entrevistas e incidentes.
Trade-offs que diré en voz alta
Inspirado en la misma conversación de arquitectura fintech:
- Velocidad vs seguridad — rate limits, validación, auth antes que features
- Simplicidad vs escalabilidad — monolito primero, servicios cuando el límite duele
- Consistencia vs disponibilidad — outbox y sagas, no exactly-once de cuento
- Costo vs rendimiento — caché y read models cuando las métricas lo pidan
No hay arquitectura perfecta — solo la que calza con el momento del producto.
Para quién es
- Backend engineers que preparan system design y entrevistas fintech
- Desarrolladores NestJS que quieren puertos y adaptadores, no services obesos
- Quien ya publicó un "repo de challenge" y quiere la segunda vuelta — más lenta, documentada
Si eres tú, guarda el hub de la serie. El repo en GitHub crecerá fase a fase; las estrellas ayudan, pero leer y cuestionar ayuda más.
Qué sigue
Artículo 1: qué ocurre realmente detrás de POST /transfer — el pipeline oculto, no el diagrama feliz.
Código: Fase 0 — bootstrap monorepo, dominio Accounts, OpenAPI, Docker Compose con PostgreSQL.
LinkedIn: versión corta de este anuncio con los mismos enlaces.
Aprendizaje en público. Corrí una vez con Arkano; ahora camino la maratón.
Portafolio: andresed.dev
