Case study 03 · UPI infrastructure
One UPI service interface across different deployment realities.
The payment service had to work across bank-managed infrastructure, certified cloud environments, and payment apps with different data-hosting requirements.
UPIRustDynamoDBPostgreSQLMulti-cloud
RoleSoftware engineer and technical lead
ScopeUPI core · multi-cloud · data access
SystemsRust · DynamoDB · PostgreSQL · Redis
Constraints
- Some PSP services moved from bank-managed on-premise infrastructure to certified GCP infrastructure.
- One payment-app integration required data hosted in its own AWS account.
- UPI services spanned multi-cloud and on-premise environments.
- Features had to pass partner and NPCI certification before release.
What I owned
- Designed a Rust dual/hybrid database interface over DynamoDB and PostgreSQL.
- Designed and implemented UPI Number Mapper to locate a payer or payee through a registered mobile number.
- Designed a distributed cache for UPI services deployed across multi-cloud and on-premise environments.
- Coordinated feature scope and delivery timelines with payment apps, partner banks, and NPCI certification stakeholders.
Outcome
- The UPI core could support different data-hosting models behind one service interface.
- The team shipped a new UPI capability without treating each PSP deployment as a separate product.
- Architecture decisions accounted for operational and certification constraints, not only application code.
What this teaches
- Separate the payment domain interface from storage and deployment choices.
- Treat deployment variation as a product constraint early, not as an integration problem at the end.
- A distributed cache needs an explicit consistency and failure model before it becomes shared infrastructure.
Standards and ecosystem references
NPCI: Unified Payments Interface ↗Confidentiality note. This is a sanitized account. Company-internal names, merchant details, ticket IDs, and private implementation data are intentionally omitted.