CLOUD MODERNIZATION FOR A HIGH-VOLUME VERIFICATION PLATFORM
Built for a high-volume identity-verification platform
An identity-verification platform was modernized into an active-active-active architecture across regions, with stateless APIs, real-time fraud scoring and portable infrastructure. The design targets 99.99% availability and a customer base of 50 million.
By Yashwant Daniel · Solvstrat
Key
Facts
- Sector
- Identity verification
- Built
- Multi-region, cloud-agnostic platform architecture
- Stack
- Kubernetes · Kafka · Redis · Kong · PostgreSQL
- Constraint
- Active-active-active; no vendor lock-in
- Outcome
- Regional failover with real-time fraud scoring
Challenges
The platform had grown into a single-region deployment with stateful services and tightly coupled integrations. Regional failure meant downtime, scaling was vertical, and the architecture depended on provider-specific components that made moving or spanning clouds impractical.
Single-region risk
A regional outage took the platform down, with no reliable failover path.
Stateful services
Session and application state lived on individual nodes, blocking horizontal scale.
Vendor lock-in
Provider-specific services made multi-cloud and portable deployment difficult.
Constraints
Active-active-active operation across multiple regions.
No vendor lock-in; core components must be portable.
Real-time fraud decisions inside the request path.
Durable event processing with no message loss during failover.
A 99.99% availability target across regional failures.
Reference
Architecture
Global traffic management
A global traffic layer distributes requests across regions and removes an unhealthy region from rotation without manual intervention.
Kong · Traffic Manager
Stateless service tier
APIs hold no session state, so any region can serve any request and capacity can be added horizontally.
Kubernetes · Stateless APIs
Event backbone
Kafka carries asynchronous work, with MirrorMaker keeping regional clusters in sync so processing survives a regional loss.
Kafka · MirrorMaker
Real-time scoring
An in-memory data layer runs fraud-scoring models close to the request, returning decisions without a round trip to a remote store.
Redis · Redis Sentinel · RedisAI
Data and observability
PostgreSQL provides durable storage and warehouse capability, while metrics and dashboards make regional health and latency visible.
PostgreSQL · Prometheus · Grafana
Data
Flow
- 1
A request reaches the global traffic layer and is routed to a healthy region.
- 2
A stateless API authenticates the caller and validates the request.
- 3
In-memory scoring returns a risk decision inside the request path.
- 4
Asynchronous work is published to the event backbone.
- 5
Kafka replicates events across regions so processing survives failover.
- 6
Results are persisted and surfaced through operational dashboards.
Delivery
Redundancy
Multi-region topology and failover design.
Stateless APIs
Removing application state from the service tier.
Security and gateway
Gateway integration and hardened access.
Fraud orchestration
Real-time scoring and event-driven decisioning.
Scale
Capacity, observability and 50M-customer readiness.
Hard
Problems
Failover without data loss
Problem: Asynchronous work in flight during a regional failure could be lost or duplicated.
Resolution: The event backbone is mirrored across regions and consumers are designed to be idempotent, so replay is safe.
Multi-region consistency
Problem: Active-active writes can conflict when regions diverge.
Resolution: State is partitioned by domain, and cross-region coordination is limited to the small set of operations that require it.
Keeping portability
Problem: Managed services simplify operations but deepen provider lock-in.
Resolution: Core services rely on containerized, open components; provider-managed services are used at the edges where replacement is cheap.
Results
Regional resilience
The architecture is designed to keep serving through a regional outage while meeting a 99.99% uptime target.
Horizontal scale
Stateless services scale out across regions as customer volume grows toward 50 million.
Portability
Core services are not tied to a single provider’s proprietary runtime.
Technology
Used
Kubernetes
Kafka
Redis
Kong
PostgreSQL
Prometheus / Grafana
Lessons
Active-active is a data problem first and a traffic problem second.
Idempotency is what makes failover safe, not the load balancer.
Portability is a set of small choices, not a single migration event.
CLIENT SUCCESS STORIES
More Case Studies
Explore how Solvstrat engineers custom digital architectures and software platforms for leading brands.
FAQ
Frequently asked questions
Active-active-active means three or more regions serve live traffic simultaneously rather than one active region and a standby. If a region fails, the remaining regions continue serving without a cold-start failover.
By removing single points of failure, distributing traffic across regions, keeping services stateless and making asynchronous processing durable and replayable. Availability is designed into the topology, not added after launch.
Core services are containerized and built on open components. Provider-specific managed services are confined to edges where they can be replaced without rewriting the platform.
The architecture is designed for it: stateless services scale horizontally, in-memory scoring avoids remote round trips, and the event backbone handles asynchronous load across regions.
SEE THE PROTOTYPE WE'D BUILD
Give us 30 minutes.
We'll show you the fix.
Tell us where the work slows you down. We'll come back with a prototype of the custom software, internal tools or automation we'd build to remove it — working in weeks, and you own the code.