[02]
One API, seven domains
Auth, business, cards, transactions, schedules, wallet and admin inject endpoints into one RTK Query base API with shared caching and invalidation.
[CASE STUDY 04][IN DEVELOPMENT]
Alfa Multi-Role Fintech Platform
A role-aware fintech platform for personal, business and admin journeys over Python microservices. I own sessions, authorisation, onboarding, verification, document handling and the client data layer.
- Role
- Full-Stack Engineer — Python microservices & Next.js client
- Timeline
- Feb 2026 – Present
- Status
- In development
- Stack
- Python, FastAPI, Supabase +9
* AUTH + SERVICE TOPOLOGY
[AT A GLANCE]
- ROLE
- Full-stack engineer — the FastAPI services and the Next.js client on top of them
- OWNED
- Session and authorisation model · onboarding and verification · document handling · the client data layer
- NOT MINE
- The banking rails — issuing, funding and exchange rates sit behind providers, and the regulated permissions are the operator's
- SURFACES
- Three journeys out of one architecture — personal, business and admin
- STATUS
- In development and pre-traffic, which is why the measures below are instrumented rather than reported
[STACK]
- Python
- FastAPI
- Supabase
- GraphQL
- Next.js 16
- React 19
- TypeScript
- Redux Toolkit
- RTK Query
- Zod
- Tailwind v4
- AWS S3
[01] The problem
Acting as the wrong account is not a UI bug
A user can hold personal and business accounts, have neither selected and be verified on only one. In a money product, unresolved identity can expose the wrong balance or payment surface. Account, role and verification state must settle before any transaction can begin.
[02] The constraints
What moving money rules out
Verification gates money, not features
Payment surfaces do not render until verification passes for the selected account. Personal and business verification states remain independent.
Identity documents are the most sensitive thing here
Passports, incorporation papers and address evidence pass through server-controlled handlers so storage credentials never reach the browser.
A capability failing must not look like the bank being down
FX, cards and top-ups depend on different providers. Each capability must degrade independently so one outage does not take down the platform.
[03] The approach
How it was built
Identity resolves once before any money-moving interface renders. Edge middleware checks token presence; a central guard resolves account, role and verification. Six FastAPI capabilities sit behind GraphQL, with authorisation enforced at both route and row level.
[KEY DECISIONS]
- [01]Resolved role, account and verification once, before any money-moving screen renders.
- [02]Limited edge middleware to checking whether a token exists.
- [03]Placed 10+ GraphQL APIs in front of six FastAPI capabilities.
- [04]Used one RTK Query base API across seven client domains.
- [05]Instrumented authorisation rate, transfer p95, reconciliation breaks and KYC completion before launch.
[04] The trade-offs
Where safety beat simplicity
[01]
Resolve identity before a money surface exists
- Instead of
- Render the dashboard and let each page check what it is allowed to show
- What it cost
- Identity resolution adds a step before the first meaningful application screen.
- What it bought
- Transaction controls never render for an unselected or uncleared account.
[02]
Authorise twice — at the route, and at the row
- Instead of
- Trust the route guard, since the client cannot reach the data without passing it
- What it cost
- Route and row-level policies both require maintenance.
- What it bought
- An application bug cannot expose another account’s financial records.
[03]
One service per financial capability
- Instead of
- One payments service, which is far less to run for a team this size
- What it cost
- Six deployables add operational overhead, and cross-capability changes need coordinated releases.
- What it bought
- Provider failures remain inside one capability instead of taking down balances, transfers and cards together.
[04]
Identity documents move through the server
- Instead of
- Upload straight from the browser to object storage with a client-held credential
- What it cost
- Route handlers must manage file size and streaming.
- What it bought
- No browser-held credential can reach the identity-document bucket.
[05] The build
What Alfa is made of
[01]
Hybrid auth model
After optional 2FA, a bootstrap provider fetches the user once. A central guard then resolves admin, dashboard, onboarding or account selection.
[03]
Verification, and the documents it runs on
Personal and business onboarding use separate paths and independently gate payment access. Identity documents move through Next.js route handlers with the AWS SDK, keeping bucket credentials off the client.
[04]
Four route groups, one set of rules
Auth, onboarding, dashboard and admin route groups share Zod schemas, keeping validation consistent from signup through later edits.
[05]
Money movement surfaces
Shared shells and form primitives support transfers, payment requests, scheduled payments, transaction history and card management across account types.
[06]
The four numbers this gets judged on
The platform emits authorisation rate, transfer p95, reconciliation break rate and KYC completion. These measures exist before traffic, but do not yet have reportable values.
[07]
p95, not the average
Transfer latency uses p95 from service entry to ledger write. Reconciliation break rate tracks movements where provider and platform records disagree at day end.
[08]
Verification, measured per step
KYC completion is measured per onboarding step because verification gates funding. Alfa is pre-traffic, so only events and thresholds exist; no outcome is claimed yet.
[06] The result
What Alfa guarantees — and what it will measure
0
Money surfaces before identity resolves
* the guard settles the account, then the screen exists
2
Layers authorising a read
* route guard, and row-level rules at the data
6
Capabilities that fail alone
* an FX outage is not a transfers outage
4
Service levels instrumented
* auth rate · transfer p95 · recon breaks · KYC completion
[HOW THESE WERE MEASURED]
Alfa has no live traffic. The first three values are verifiable architecture properties; the fourth counts instrumentation, not output. Authorisation, latency, reconciliation and KYC will carry values only after production traffic exists.
[07] What I’d do differently
Honestly
Money movement and authentication need broader integration and end-to-end coverage. That is the next priority before onboarding analytics or staged rollout controls.
Written by Faizan Amir
Role on Alfa: Full-Stack Engineer — Python microservices & Next.js client
Last reviewed
Need something like this built?
Next case study [05]
WisdomUp
Multi-Service E-Commerce Platform
Read the case study →
