You tap Send on a transfer. The app shows a spinner for a second, then Done.
What you do not see: API gateway routing, auth, balance checks, ledger entries, fraud rules, event publishing, notifications, observability traces, and a dozen trade-offs that decided whether money moves safely or fast — or both.
I have shipped backends for years. I still catch myself thinking a fintech is "a CRUD with a balance column." It is not. That gap — between what users see and what engineering must get right — is why I am starting a new public series today.
The spark: someone else's diagram
Emiliano Mauro López published a breakdown of what sits behind a modern fintech: gateway, auth, core services, fraud, Kafka, Redis, S3, observability, AWS, compliance. Nothing exotic for a senior backend audience — but laid out as decisions, not buzzwords.
One line stuck with me:
The difference between a fintech that scales and one that collapses is internal system design.
I had seen those boxes before, in fragments, across production systems. The post did not teach me new nouns. It gave me permission to stop collecting repos and start connecting the story in public.
The starting point: a technical challenge against the clock
A few months ago I took a technical test and published the result: arkano-banking-challenge.
It worked. I delivered on time. Accounts, movements, the shape of a small banking API — enough to pass the bar.
What I did not leave behind was depth:
- Why this boundary and not another?
- What breaks when Kafka redelivers the same event?
- When is a modular monolith smarter than six microservices on day one?
Since then I kept building backends with higher standards — event-driven demos, NestJS starters, production APIs. The Arkano repo stayed a bookmark: you can sprint; now learn to explain.
This series is not a fork of that repository. I am rebuilding from zero, on purpose, at a pace where each phase documents the why, not just the what.
What I am building (and what I am not)
fintech-core-platform (open source, phased) is a reference backend:
- NestJS, TypeScript strict, hexagonal boundaries
- PostgreSQL for transactional data
- Redpanda (Kafka API) for events in local dev
- MiniStack for AWS services in dev (S3, Secrets Manager, SES)
- OpenAPI, tests, CI — one phase at a time
What it is not:
- A licensed bank, SPEI/ACH production rails, or full AML/KYC compliance
- A clone of every box in an enterprise diagram on week one
- A race to microservices for LinkedIn screenshots
The goal is demonstrable senior backend craft: explicit trade-offs, production patterns (outbox, idempotency, DLQ), and an architecture that evolves from a modular monolith toward event-driven services — when the domain justifies the cost.
How this series is structured
Each release pairs a long-form article on this blog (depth, diagrams, lab steps) with open source code on GitHub, one phase at a time. LinkedIn posts are short summaries linking back here.
Series index: makingcode.dev/series/fintech-core-platform
The roadmap (high level)
| Phase |
Topic |
Idea |
| 0 |
Modular monolith |
Hexagonal Accounts module — no premature microservices |
| 1 |
Ledger & money |
Integer cents, invariants, no floating point |
| 2 |
Events |
Redpanda, outbox, idempotent consumers, DLQ |
| 3 |
Payments |
Provider adapter, webhooks, saga lite |
| 4 |
Auth & limits |
JWT, RBAC, Redis rate limiting |
| 5 |
Fraud |
Rules before ML |
| 6 |
Platform |
Notifications, observability, S3 receipts |
| 7+ |
Gateway, KYC lite, AWS deploy |
Stretch goals, documented honestly |
Each phase maps to one or more articles and one LinkedIn post. I will not skip the "boring" foundations — that is where interviews and incidents actually live.
Trade-offs I will name out loud
Inspired by the same fintech architecture conversation:
- Speed vs security — rate limits, validation, auth before features
- Simplicity vs scalability — monolith first, services when boundaries hurt
- Consistency vs availability — outbox and sagas instead of fairy-tale exactly-once
- Cost vs performance — cache and read models when metrics say so
No perfect architecture — only architecture that matches the moment of the product.
Who this is for
- Backend engineers preparing for system design and fintech interviews
- NestJS developers who want ports and adapters, not fat services
- Anyone who shipped a "challenge repo" once and wants the second lap — slower, documented
If that is you, bookmark the series hub. The GitHub repo will grow phase by phase; stars help, but reading and questioning helps more.
What comes next
Article 1: what really happens behind POST /transfer — the hidden pipeline, not the happy path diagram.
Code: Phase 0 bootstrap — monorepo, Accounts domain, OpenAPI, Docker Compose for PostgreSQL.
LinkedIn: a short version of this announcement with the same links.
Learning in public. Sprinted once on Arkano; walking the marathon now.
Portfolio: andresed.dev
