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.

Important The metrics below must match reality. If they’re placeholders, label them as “target” or remove them.

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

Uptime 99.98% (verify)
Peak throughput ~1,800 TPS (verify)
Daily volume $4.2M (verify)
Security incidents 0 (verify)
Recruiter tip: replace “(verify)” with real measured values or remove numbers.

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

Links

Add: screenshots/GIFs, a 60–90s demo video, and a short “security + audit model” diagram.