Ravindra BagaleCourses & study guides Track your progress

Guides

Paytm Architecture Explained: How Paytm Runs Payments on the Cloud

Short answer: Paytm runs mainly on AWS. In 2022 Paytm had 100+ AWS accounts, thousands of servers, petabytes of cloud storage and thousands of microservices, and also uses Azure and Google Cloud. Services run on EC2 Auto Scaling groups behind ALBs, with many Spot instances. Payment databases use a Paxos consensus setup across data centres so every transaction is stored on most machines. Caching uses Redis, monitoring uses Prometheus and Thanos.

Suppose you recharge your mobile on Paytm

You recharge your prepaid mobile for 299 rupees on Paytm in Lucknow. In simple terms:

  1. Your app's request reaches an Application Load Balancer on AWS.
  2. The ALB sends it to a microservice running on EC2 instances in an Auto Scaling group.
  3. Session and hot data come from Redis clusters.
  4. The payment is recorded in a database cluster that uses Paxos, so it is safely written on the majority of machines in different data centres.
  5. Metrics from each service are collected by Prometheus and shown to Paytm's operations centre.
  6. Later, the transaction data flows into Paytm's data platform on Amazon EMR and S3 for reports.

All of this happens in a few seconds. Paytm accepts payments from Paytm Wallet, Paytm Postpaid, UPI, netbanking and cards, and each business (for example IoT payment devices in stores or merchant account status) has its own database cluster, sized for unpredictable reads and writes.

What architecture style does Paytm use?

Paytm (22 to 2023) shows a large microservices estate on AWS.

  1. Thousands of microservices across 100+ AWS accounts and 100+ business verticals (2022).
  2. Canary deployments: Jenkins builds, AWS CodeDeploy rolls out to canary and live target groups behind the ALB, with Spot instances handled gracefully.
  3. Cost control: Paytm built the Paytm Optimizer tool to track cloud cost and move Auto Scaling groups to Spot safely.
  4. Strong databases: sharding, a single-leader Paxos design and InnoDB tuning for payment data (2022).

Paytm architecture diagram (public parts)

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

Watch the orange dot follow each numbered step.
Paytm architecture from public information (simplified)AWS (100+ accounts)Data platform on AWSSimplified; based on publicly shared information.Paytm userappALBcanary + live target groupsMicroservicesEC2 ASG (Spot) + KubernetesRedis clustersmain cache layerPayment databasesPaxos, sharded, InnoDBS3build artifacts, metricsPrometheus + ThanosGrafana, PagerDutyAmazon EMR + S3Spark, 250K reports/day
  1. You start a recharge.
  2. An ALB on AWS receives it.
  3. A microservice on EC2 handles it.
  4. Session data comes from Redis.
  5. The payment is stored with Paxos replication.
  6. Builds and long-term metrics live in S3.
  7. Prometheus and Thanos collect metrics.
  8. Data later flows to EMR for reports.
  9. Recharge successful.
Diagram 1: the public parts of Paytm's architecture. Simplified; based only on publicly shared information. Open the diagram as an image (PNG) · WebP

What does Paytm use? Main technologies

LayerWhat Paytm uses (public)What it does in simple words
CloudAWS (also Azure, Google Cloud)Hosts Paytm services
ComputeEC2 Auto Scaling groups, Spot, KubernetesRuns microservices
DeploysJenkins + AWS CodeDeployCanary and live rollouts
DatabaseSharded, Paxos-replicated, InnoDBPayment records
CacheRedis clustersFast reads
MonitoringPrometheus, Thanos, GrafanaMetrics and alerts
DataAmazon EMR, S3, SparkReports and analytics

Which cloud provider does Paytm use?

Paytm uses AWS as its main cloud. As of 2022 Paytm uses the clouds AWS, Azure and Google Cloud, with 100+ AWS accounts. The setup meets data localisation and compliance rules.

How does Paytm deploy new code safely?

Since 2022 Paytm uses a canary rollout on AWS:

  1. Jenkins builds the code and packages it with an appspec file.
  2. The build is uploaded to S3.
  3. New canary instances are launched in their own Auto Scaling group and target group.
  4. Health checks run on the canary; if healthy, it is made active in the ALB, which splits traffic between canary and live target groups.
  5. Engineers watch the canary, then approve the live rollout or abort and roll back.
  6. On Spot instances, a small system process checks the AWS metadata API for interruption notices and stops the app gracefully before AWS takes the machine back.

The Paytm Optimizer (2022) adds a scheduler that predicts Spot interruptions from data across thousands of instances, so large Auto Scaling groups can safely use Spot in both peak and non-peak hours.

How it started: on-premises data pipeline

  1. Paytm's central data pipeline once ran on premises on a proprietary system; jobs took 8 to 10 hours.
  2. A 10-engineer team moved it to Amazon EMR, S3 and Spark in about four months, cutting job times to 20 to 30 minutes and using an 80:20 Spot to On-Demand ratio.
  3. Monitoring moved from paid tools to open-source Prometheus.

How does Paytm store data?

  1. Payment databases: sharded clusters with Paxos consensus and InnoDB.
  2. Redis: main cache layer across hundreds of AWS accounts (2023).
  3. S3: build artifacts, long-term metrics and the data lake.
  4. The current main database product names are not publicly shared.

How does Paytm monitor its systems?

  1. Prometheus with EC2 and Kubernetes service discovery.
  2. Thanos as global query layer, metrics stored long-term in S3.
  3. Alertmanager sends alerts to Slack, MS Teams, PagerDuty and email; a NOC watches a single view.

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

Please read this first

This section is a learning design by Ravindra Bagale. It is not Paytm's real setup. Paytm really runs mainly on AWS. We use AWS here because it is what you learn in the AWS course.

Suppose you want to build "BillBhai", an app to pay electricity and mobile bills. Here is a simple AWS layout.

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 with canary target groups.
  2. Services on EKS (or EC2 Auto Scaling groups like Paytm).
  3. Use Spot for stateless services.

3. Storage and databases

  1. Aurora for the ledger.
  2. DynamoDB for history.
  3. ElastiCache for Redis for sessions; S3 for receipts.

4. Monitoring

  1. Amazon Managed Prometheus + Grafana, or CloudWatch.
  2. X-Ray traces.

Request flow diagram

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

Watch the orange dot follow each numbered step.
If we built a Paytm-like app on AWS (illustrative)AWS Region (for example ap-south-1, Mumbai)VPC 10.0.0.0/16Availability Zone AAvailability Zone BPublic subnet 10.0.1.0/24RT: 0.0.0.0/0 → IGWPublic subnet 10.0.2.0/24RT: 0.0.0.0/0 → IGWApp subnet 10.0.11.0/24RT: 0.0.0.0/0 → NATApp subnet 10.0.12.0/24RT: 0.0.0.0/0 → NATData subnet 10.0.21.0/24RT: local onlyData subnet 10.0.22.0/24RT: local onlyvia VPC endpointsIllustrative learning design only. This is NOT the company's real setup.Userphone appRoute 53DNS lookupCloudFrontCDN edge cacheAmazon S3receiptsIGWApplication Load Balancerspans both AZsNAT gatewayNAT gatewayBill-pay APIEKS pods (auto scaling)Bill-pay APIEKS pods (auto scaling)ElastiCachesessions, operatorsAuroraledger, usersElastiCachesessions, operatorsAuroraread replicaSQS FIFOpayment eventsDynamoDBpayment historyCloudWatch + X-Raymetrics, logs, traces
  1. You open BillBhai. Route 53 answers.
  2. Static files via CloudFront.
  3. From S3.
  4. API calls enter via the internet gateway.
  5. The ALB picks a pod.
  6. The bill-pay API runs.
  7. Session from ElastiCache.
  8. Ledger in Aurora; history in DynamoDB.
  9. Events to SQS FIFO.
  10. CloudWatch watches.
  11. Bill paid.
Diagram 2: an illustrative AWS design for learning. Paytm does not necessarily run like this; see the sections above for what is publicly known. Open the diagram as an image (PNG) · WebP

Paytm versus our AWS design

PartPaytm (public info)Our AWS design
CloudAWS (+ Azure, GCP)AWS
ComputeEC2 ASG + Spot, KubernetesEKS
DatabasePaxos-replicated shardsAurora
CacheRedisElastiCache
MonitoringPrometheus + ThanosManaged Prometheus / CloudWatch

Quick quiz: check what you learned

  1. Which cloud does Paytm mainly use?

    1. AWS
    2. Oracle Cloud
    3. IBM Cloud
    4. Only own servers
    Show answer

    A. Paytm has 100+ AWS accounts.

  2. Which consensus algorithm do Paytm's payment databases use?

    1. Bitcoin
    2. Paxos
    3. Gossip
    4. Round robin
    Show answer

    B. Paytm chose a single-leader Paxos design.

  3. What does Paytm use for monitoring?

    1. Excel sheets
    2. Nagios only
    3. Prometheus and Thanos
    4. No monitoring
    Show answer

    C. Prometheus with Thanos and Grafana.

  4. Where did Paytm move its data pipeline?

    1. Floppy disks
    2. Google Sheets
    3. A mainframe
    4. Amazon EMR and S3
    Show answer

    D. Paytm moved to Amazon EMR, S3 and Spark.