Overview
Overview
A sober, proven architecture sized for your constraints.
Our choices do not come from a catalogue. They follow, one by one, from four figures in your specification: ≤ 3 seconds on 4G, 99.5% availability, 2,000 concurrent users, and a roadmap that reaches all the way to banking. Add FR/EN bilingual, partial offline and bank-grade security, and you get the set of constraints below — translated into a system.
The end-to-end architecture
Here is ERK+ in full — from a site manager's smartphone all the way to encrypted backups replicated across three sites. Each node carries its technology's real logo; the dots travelling along the links are actual requests in flight.
ERK+ · live flow & traffic
real requests, drawn to scale
Every client speaks only to the Go gateway over TLS 1.3; the gateway fans out to isolated services; data never leaves its layer. Dots are requests in flight.
Every layer has a single responsibility and a single reason to change. The client never talks directly to the database; the database never knows a user's identity; the business core has no idea whether it was called from the web, iOS or the desktop app. This separation is not theory: it is what makes a system auditable, testable and fixable under pressure.
The same stack, seen in volume
Six layers, one deployment
The style: a modular monolith
We take a deliberate stance against the microservices fashion. ERK+ is a modular monolith: the logical boundaries are those of microservices, but there is only one artefact to deploy, monitor and keep at 99.5%.
| Classic microservices | Modular monolith (our choice) | |
|---|---|---|
| Internal latency | Network between services | None — in-memory calls |
| Infra cost | High (N services, N databases) | Divided — decisive on an African budget |
| Operational complexity | Orchestration, service mesh | One deployment, a team of three |
| Transactions | Distributed, fragile | Native ACID — critical for payments |
| V2 evolution | Already fragmented | Extraction module by module, no rewrite |
The bet is simple: at ERK+'s scale (one company, a few thousand users) the cost of microservices is paid up front without the benefit. The day the V2 marketplace requires pulling the Payments module out into its own service, the event bus is already there to do it cleanly — without touching the rest.
Ready for your V2 and V3
- Module boundaries aligned with your 8 functional families — not with database tables
- The V1 payment ledger is already structured for multi-merchant flows (V2) and financial products (V3)
- A versioned, documented API from day one: what is published never breaks an existing client