Guides

PhonePe Architecture Explained: How PhonePe Handles Billions of Payments

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: PhonePe runs its systems in two data centres in active-active mode: both handle live traffic, so one can fail without stopping payments. It uses data centres, not a public cloud region. Transaction history lives in TStore, built on HBase with Elasticsearch for complex queries (2024). Kafka carries about 100 billion events a day (2023). Chat-style payment timelines run on Bullhorn (2025) and real-time analytics on Garfield, built on Apache Druid (2025).

Suppose you pay your friend through UPI on PhonePe

You split a dinner bill in Hyderabad and send your friend 450 rupees on PhonePe. In simple terms:

1. Your app sends the payment request to PhonePe's servers in one of its two data centres.
2. PhonePe's payments orchestrator runs the money flow and talks to the UPI network and banks.
3. The transaction is written to TStore, whose main store is HBase.
4. Events about the payment go into Kafka; MirrorMaker 2 copies them to the other data centre.
5. Your chat-style timeline with your friend is updated through Bullhorn, PhonePe's pub-sub platform.
6. Dashboards on Garfield (Apache Druid) show payment success rates in real time to engineers.

What architecture style does PhonePe use?

PhonePe focuses on building strong shared platforms early.

1. Platform first: in 2019 PhonePe prioritised platform capabilities and system scaling over growth hacks, with a generic payments orchestrator for all money flows.
2. Active-active everywhere: TStore and Garfield both run in two data centres at the same time.
3. Polyglot storage (2024): HBase is the source of truth, Elasticsearch handles aggregations; Kafka and RabbitMQ move messages.
4. Event backbone: Kafka with separate write and read clusters in each data centre (2023).

PhonePe architecture diagram (public parts)

This diagram shows only what PhonePe or its partners have shared publicly. Press Play to follow a request step by step.

What does PhonePe use? Main technologies

Which cloud provider does PhonePe use?

PhonePe runs two geographically separate data centres running active-active. There is no public record of a public cloud like AWS for the core payments path. Exactly who owns and runs the data centre hardware is not publicly shared.

How does PhonePe keep payments running if a data centre fails?

The 2024 TStore design in detail:

1. Two full copies: TStore runs two independent clusters in separate data centres. Both take reads and writes.
2. Routing by config: a Discovery Service backed by a central ZooKeeper cluster tells the TStore client where to send writes, so traffic can be shifted quickly.
3. Replication: each data centre has its own Kafka cluster; MirrorMaker 2 streams topics to the other side, so writes made in one cluster are applied in the other with little delay.
4. Failed messages: messages that cannot be processed go to RabbitMQ dead letter exchanges for separate handling.
5. Kafka layout (2023): PhonePe moved from one Kafka cluster per data centre to separate write and read clusters per data centre, and services send events through a client library and an ingestion service.

Bullhorn (2025) reuses this kind of platform thinking: one pub-sub system powers peer-to-peer payment chats and the in-app inbox for alerts, which is more reliable than push notifications that people can easily dismiss.

How it started: PhonePe in 2019

1. In May 2019, three years after launch, PhonePe had over 150 million users, 10 million daily transactions and 2 billion data events per day.
2. Its core payments orchestrator used a flexible Databuilder framework to support all types of money flows.
3. Risk detection and offers used a generic in-house entity store for real-time aggregation.

How does PhonePe store data?

1. HBase on large HDFS fleets: transaction data (TStore).
2. Elasticsearch: aggregations and search over transactions.
3. Apache Druid: real-time analytics with 5:1 rollup (Garfield).
4. Data is replicated between the two data centres (Kafka MirrorMaker 2 and cluster replication).

How does PhonePe monitor its systems?

1. Garfield turns raw events into real-time dashboards for incident detection, at about 40,000 messages per second peak (2025).
2. Other monitoring tools are not publicly shared.

If we built an app like PhonePe on AWS (illustrative)

Suppose you want to build "PaisaPal", a payments app for a co-operative bank. Here is a simple AWS layout. Real payment apps must also follow RBI and NPCI rules.

1. Network: VPC, subnets, route tables, gateways

1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

1. ALB in public subnets with AWS WAF.
2. Payment services on EKS in private subnets.
3. SQS FIFO queues keep payment events in order.

3. Storage and databases

1. Aurora for the ledger (strong consistency).
2. DynamoDB for transaction history.
3. ElastiCache for sessions; S3 for statements.

4. Monitoring

1. CloudWatch alarms on payment success rate.
2. X-Ray traces; CloudTrail for audit.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

PhonePe versus our AWS design