Sizing the infrastructure
A worked out reference for 25 million transactions per month, with the sizing rationale for each layer using AWS instances as a reference.
Reference architecture
This is complete, per-service footprint at a common entry-level production volume for enterprise self-hosting. You may use it as a starting point and adjust against your own inputs.
Traffic assumptions
The sizing approach is based on below numbers.
The request rate assumes 7 requests per transaction. 1 TPS = 7 RPS
While the ratio is a standard, it may also be affected based on your integration pattern, business use cases.
Transaction volume
25 million per month
Transactions per second
~10 TPS
Requests per second
~70 RPS (1 TPS = 7 RPS)
Traffice surge (steady increase)
10x
Traffic spikes (sudden increase)
Not applicable.
Note: To keep it simple, the sizing approach below does not consider provisioning for traffic spikes, which could be usually 5x to 10x of the steady state TPS. Such spike traffic, its frequency and predictability depends on the nature of your business. The Juspay team will help you with a custom sizing plan to provision for such requirements.
Application cluster
Hyperswitch's OLTP Router application running on 1 pod with 1 vCPU can handle upto approximately 40 RPS. Hence, it needs a minimum of 2 vCPUs — the minimums below are higher because two pods is a capacity floor, not an availability posture.
Four principles shape this table:
Every service runs at least two pods: With additional buffer on critical services. The OLTP Router path carries the most number of pods. And the maximum number of pods also has a dependency on the database capacity (discussed in below sections)
Additional headroom for throughput: There shall be an additional 50% compute headroom for the stated throughput of 40 RPS per 1vCPU.
Maximum pods and nodes are set high for critical services: These are ceilings for spiky traffic, not provisioned capacity. Setting them low saves nothing and caps your ability to absorb a surge. Some services could be exceptions (stated in below table) as it does not scale with traffic, so its ceiling stays low.
Node instance types are deliberately diverse: Listing several instance types prevents a chokepoint if one type cannot be provisioned due to regional or technical unavailability. This is a real failure mode during a scale-up event, and it is free to avoid.
OLTP Router
Traffic-scaled
4
50
1 / 1.5 core
1 / 1.5 GB
Payment Methods
Traffic-scaled
3
50
0.5 / 1.0 core
0.5 / 1.0 GB
Scheduler (Producer)
NA
1
1
1 / 1.5 core
1 / 1.5 GB
Scheduler (Consumer)
Traffic- scaled
1
10
1 / 1.5 core
1 / 1.5 GB
Decision Engine
Traffic-scaled
2
50
0.4 / 1 core
0.4 / 1 GB
Connector Service
Stateless
3
20
0.4 / 1 core
0.5 / 1 GB
OLAP Router
Operator-scaled
3
50
1 / 1.5 core
1 / 1.5 GB
Superposition
Operator-scaled
2
5
1 / 1.5 core
2 / 3 GB
Control Center
Operator-scaled
2
10
0.2/ 0.4 core
0.2 / 0.5 GB
Payment Methods is deployed as a separate release of the same chart and image as the router, so it can scale independently of it. Expect a traffic-scaled profile similar to the router's, if the payment flows are significantly saved card payments or recurring transactions.
Connector Service is stateless. It carries payment processor integrations, so its load tracks outbound call volume rather than inbound TPS. If your transaction mix weighted toward connectors that need multiple calls per payment will push it harder than the transaction count suggests. However, being stateless, it takes a high ceiling safely.
Control Center serves the operator dashboard. Its load comes from concurrent operators, not from payment volume. If the control center is only for your internal use, two pods for availability is usually sufficient; raise it with the Juspay support team, only if you distribute the dashboard across 1000s of users, or have significant analytics use.
Node pool, shared across all the above services shall be:
Minimum nodes
3
Maximum nodes
50
Instance types (AWS instances as reference)
c5.2xlarge, c5a.2xlarge, c6a.2xlarge, c5.4xlarge, c5a.4xlarge, c6a.4xlarge
Payment processing is not the only consumer of cluster compute. The service mesh, Kubernetes management overhead and telemetry daemon sets all require vCPU on every node.
These are routinely omitted from first-pass estimates, and cross validated during the load testing in Milestone IV.
Application database
Both writer and reader are sized at 4 vCPU. The workload is write-heavy, and the reader sits on the failover path — undersizing it means failing over into an instance that cannot carry the load.
IOPS is applicable at 20 per transaction, extrapolated to 10 TPS with a 5× safety factor to absorb connection spikes up to 1,000 concurrent connections.
The database shall run on Multi-AZ with a primary writer and a secondary read replica.
OLTP Service, Payment Methods, Decision Engine, Scheduler (Producer/ Consumer)
8
~64 GB
6,000
r5.xlarge
Superposition
2
~16 GB
3,600
r5.large
How the databases are grouped?
Two deliberate decisions here, and both save cost without compromising isolation where it matters.
OLTP Router, Payment Methods, Scheduler and Decision Engine share one physical database with logical separation. They have compatible access patterns and a shared failure domain is acceptable between them.
Connector Service needs no database or cache — it is stateless by design. Control Center reads through the reader database (replica) rather than holding its own. However, payment. list, analtiucs may demands heavy read workload. In such case it is advisable to not use the reader and have a dedicated database instance with replication.
Superposition runs standalone. It is not a critical-path service as it can run from cache, and its usage pattern should not be able to interfere with Hyperswitch. It needs no read replica either.
Cache
Redis runs in cluster mode with a multi-shard, multi-node setup, at least one replica per node, and Multi-AZ enabled.
Rate limiter, OLTP Router, Superposition, Decision Engine, Card Vault
2
>6 GB
2 — master and replica
3
m5.large
Three shards with a master and replica each gives six nodes in total. Cluster mode allows shards to be added later without re-architecting.
Card vault
Roughly 50% of transactions are assumed to touch the vault, so 10 TPS translates to about 5 TPS of vault traffic.
Vault traffic
~5 TPS
Compute
2 x 4 VCPU
Memory
2 x 8 GB
Instance
2 × c5.xlarge
The vault is not operated on Kubernetes and cannot autoscale. The key custodian model means a new instance cannot join the pool without human intervention, so capacity cannot expand when traffic surges. Hence, replicas and capacity must be provisioned for your peak, deliberately over-provisioned for safety.
Card vault database
Multi-AZ with a writer and reader, on the same write-heavy reasoning as the application database.
Compute
~8 vCPU — writer 4 vCPU and reader 4 vCPU
Memory
~32 GB
IOPS (Baseline)
6,000
Instance
db.r5.xlarge
What this does not include?
Size the below components separately.
Analytics and data processing service — ClickHouse, Kafka, OpenSearch and the Sessionizer. Its footprint is driven by the metric cardinality and log retention. The sizing is dependent on component count and retention policy instead.
Ingress, egress and content delivery service — Sized separately, and often already provided at organization level.
Scaling from the baseline setup of 10 TPS
The 10 TPS architecture is a baseline, not a ceiling. When your inputs differ:
Your requests-per-transaction ratio is higher
Scale pod counts, database vCPU and IOPS proportionally. This ratio drives both
Traffic surges are frequent or sustained
Raise minimum pods rather than relying on the ceiling; autoscaling may have lags with payment path may not tolerate
You deploy the card vault
Add its footprint, provisioned for peak, and its own Multi-AZ database
You need dashboard analytics at volume
Add the data processing stack, manually provisioned with Juspay support
Exptected throughput grows past roughly 400 TPS
Treat it as an architecture conversation with Juspay support team.
Last updated
Was this helpful?