1. Problem Statement & System Requirements
Digital wallet platforms must process thousands of financial state changes per second without risking balance drift, double debits, or regulatory non-compliance. The system was designed to fulfill four primary requirements:
- Bank Indonesia SNAP BI Compliance: Strict implementation of ASPI standard cryptographic signatures (Asymmetric RSA-SHA256 & Symmetric HMAC-SHA512).
- Atomic Double-Entry Bookkeeping: Every transaction must record balanced debit and credit entries (`Assets = Liabilities + Equity`) with zero float discrepancies.
- High Concurrency & Low Latency: Sub-50ms P99 API response times under 5,000 requests per second.
- Strict Idempotency: Safe retry execution on timeout failures without duplicate balance deductions.
2. High-Level System Architecture
[Client App] ──(RSA-SHA256 B2B Token)──▶ [API Gateway & Auth Service]
│
▼ (JWT Bearer)
[Client App] ──(HMAC-SHA512 /transfer)──▶ [Core Wallet Engine (Go Clean Arch)]
│
┌─────────────────────────────────┼─────────────────────────────────┐
▼ ▼ ▼
[Redis Idempotency Lock] [PostgreSQL DB (Pessimistic Lock)] [Apache Kafka Event Bus]
`lock:payment:{ext_id}` `SELECT ... FOR UPDATE` `payment.created`
│
▼
[Settlement & Recon Worker]
3. Key Engineering Decisions & Rationale
Senior backend engineering is defined by sound architecture judgment rather than technology buzzwords:
- Why Go (Golang)? Go's lightweight goroutine scheduler, minimal memory footprint (~4MB per pod), and lack of heavy JVM warm-up make it the optimal language for low-latency financial gateways.
- Why Apache Kafka? Decouples immediate transaction acceptance from downstream batch settlement, fraud scoring, and audit logging with zero event loss.
- Why PostgreSQL with Pessimistic Locking? Guarantees serialized balance updates via `SELECT ... FOR UPDATE` preventing race conditions during simultaneous deposits and withdrawals.
- Why Redis Distributed Lock? Implements sub-millisecond idempotency enforcement to intercept duplicate network retries before hitting the database.
4. Architecture Trade-offs (Advantages vs Disadvantages)
✅ Event-Driven Kafka (Pros)
- Zero API latency impact for heavy downstream auditing.
- Guaranteed replayability in case of bank settlement downtime.
- Decoupled worker squads can scale independently.
⚠️ Eventual Consistency (Cons)
- Requires robust reconciliation workers for final settlement status.
- Duplicate message filtering required at consumer boundaries.