The architectural decisions behind the wallet core and satellite systems of a top Vietnamese e-wallet — and what we'd do differently.
"Microservices" is often read as splitting everything apart. In practice the value isn't in the number of services but in drawing the right boundaries — around business capabilities, not around the org chart.
Building the wallet core and satellite systems for a national-scale e-wallet, we processed millions of transactions under strict requirements for consistency, security and scalability. Here are a few lessons that survived contact with production.
1. Service boundaries follow the business
A service should own a complete business capability and its data. If two services must change together on every update, that's a sign the boundary is wrong — they should be one.
2. Event-driven for what doesn't need to be synchronous
- Money movement needs strong consistency — handle it synchronously, with idempotency.
- Notifications, reconciliation, analytics — push through events, process asynchronously so they don't block the main flow.
- Each event is a fact that happened, not a command — new consumers can be added without touching the producer.
3. API-first with clear contracts
Defining API contracts before coding lets teams work in parallel and reduces painful integration at the end. Every contract change is versioned and never breaks existing consumers.
Microservices don't give you speed for free — they trade complexity in code for complexity in operations. Only pay that cost when scale genuinely demands it.
What we'd do differently
Start with fewer services. A well-modularized monolith, split gradually as scaling pressure appears, is almost always cheaper than splitting too early and merging back later. Observability infrastructure should exist before the second service, not after the tenth.