Executive Summary
Blackawale is a multi-tenant, cloud-native wallet-as-a-service platform designed with three non-negotiable first-class concerns: authentication, role-based access control (RBAC), and auditability.
The Problem
A growing fintech operator expanded across multiple markets and enterprise customers, but the legacy platform accumulated architectural debt that made compliance and reliability hard to sustain.
Key pain points
- Fragmented identity/session logic across services
- Hardcoded permissions per endpoint, costly to evolve
- Audit logs stored as mutable operational data (tamper risk)
- Throughput constraints and cascading failures under load
Root-cause analysis
The systemic issues mapped to three compounding causes: identity fragmentation, permission sprawl, and audit opacity—amplified by synchronous call chains and weak isolation between critical paths.
The Solution
The platform was engineered around “security and auditability as load-bearing walls”, not add-ons. Every decision was evaluated against three lenses: (1) prevent privilege escalation, (2) prevent silent tampering, (3) enable reconstruction from logs/events.
Authentication (zero-trust identity)
- OAuth 2.0 flows for client apps; service-to-service credentials where needed
- Short-lived JWTs with strong signing and key rotation
- Session hardening patterns (rotation, invalidation, anomaly triggers)
- MFA enforced for admin roles
Authorization (RBAC with policy discipline)
- Hierarchical roles and resource/action permissions
- Policy evaluation logged for allow/deny outcomes (forensics-ready)
- Permission changes tracked with append-only history and effective dates
- Cache strategy to keep authorization latency predictable
Auditability (tamper-evident logging)
- Append-only audit events emitted for every sensitive mutation
- Cryptographic chaining of entries (tamper evidence)
- Separate write path with UPDATE/DELETE denied at the database level
- Archival to durable storage with retention and integrity checks
Ledger correctness
- Double-entry ledger model (debit + credit) inside a single ACID transaction
- Idempotency keys to prevent double-charge on retries
- Concurrency controls (locking/versioning) to avoid balance anomalies
- Settlement state machine for pending/cleared flows
Lessons learned
- Start load testing early to catch N+1 and hot paths before launch pressure
- Contract testing reduces integration drift between auth/authorization boundaries
- Define SLOs upfront to prevent late-stage ambiguity on uptime/latency targets
Closing
The highest value decisions were the principled, “boring” ones: append-only writes, short-lived tokens, predictable authorization, and refusing to compromise audit integrity.
Results
Architecture
High-level flow .
[Web / Mobile Clients] | v [Edge: WAF + TLS + Bot protection] | v [API Gateway] - JWT pre-verify - Rate limiting per tenant - Request validation | +--> [Auth Service] | +--> [RBAC / Policy Engine] | +--> [Wallet + Ledger Services] | v [PostgreSQL] - tenant isolation - append-only audit schema | v [Event Bus / Outbox] - audit/event stream - consumers (reports, notifications, archiver)
Technology stack
Frontend: Next.js / React / Tailwind Mobile: React Native (optional) Backend: Node.js (NestJS) + services Auth: OAuth2 + JWT/JWK RBAC: Policy engine + cache Data: PostgreSQL + Redis Infra: AWS + Terraform + CI/CD Observability: OpenTelemetry + dashboards