Hybrid Cloud Infrastructure for a BNPL Fintech
AWS ECS · GCP Cloud Run · Terraform · PCI DSS · IPsec Bank VPNs
- QisstPay is a Buy Now Pay Later fintech, which means every piece of infrastructure touches regulated financial data. I joined as a DevOps Engineer when the platform ran almost entirely on AWS with manual, inconsistent deployments.
- Over 20 months I co-owned the migration of 17 backend microservices (Python, Java, Go) to GCP Cloud Run, maintained PCI DSS compliance across AWS workloads and the office network, and built the secure VPN integrations with banks and telecom providers used for credit scoring.
- The result was a hybrid AWS + GCP platform processing 1M+ daily transactions, with autoscaling, faster builds, and audit documentation that survived PCI DSS review.
The Challenge
Constraints
- PCI DSS compliance was non-negotiable and continuously audited -- every infrastructure change had to be defensible to an assessor.
- Financial partners (banks, telecoms) dictated their own VPN parameters and timelines; I adapted to them, never the reverse.
- Zero-downtime expectations: BNPL checkout is revenue-critical -- an outage is merchants losing sales in real time.
- I worked within a platform/DevOps team.
Key Decisions
Where to run the 17 microservicesCloud Run for the stateless microservices, ECS retained for stateful payment services
Considered: Stay on AWS (ECS everywhere) / GKE / GCP Cloud Run
Why: Cloud Run provided per-request pricing and zero capacity planning for stateless workloads. ECS stayed for services needing persistent VPN connections where cold starts were unacceptable.
Trade-off: Two clouds means two IAM models, two networks to secure, and PCI scope documentation spanning both. I accepted the operational overhead because the autoscaling and cost model justified it.
How to keep two clouds consistentSingle Terraform codebase, separate state per environment
Considered: Console-driven setup per cloud / Terraform with per-cloud modules in one repository
Why: Auditability: when the PCI assessor asks "who changed this security group and when," the answer is a git commit, not a memory.
Trade-off: Terraform state management across two providers and multiple environments was its own overhead. Emergency console changes happened and caused drift that required manual reconciliation.
VPN architecture for bank/telecom integrationsPer-partner dedicated IPsec tunnels
Considered: Managed VPN gateways / Self-managed IPsec instances / Per-partner dedicated tunnels
Why: Each financial institution had unique IPsec parameters and certificate requirements. A shared hub would have required all partners to agree on common settings, which was not realistic.
Trade-off: More tunnels to monitor and maintain. Each partner integration was its own project with its own timeline.
PCI DSS scope boundaryNetwork-segmented cardholder data environment with minimized scope
Considered: Treat everything as in-scope / Segment a cardholder data environment and minimize scope
Why: Every system in PCI scope multiplies audit burden -- segmentation is the difference between auditing a room and auditing the building.
Trade-off: Segmentation required strict network policies and careful routing. Services that needed cardholder data had to be explicitly placed inside the CDE.
The Approach
System Architecture
Hybrid Cloud Architecture
Click any component to see how it fits into the hybrid cloud architecture.
Interactive Demo
Walk through the system design and data flow for this project step by step.
The transaction crosses two cloud providers and two private networks in under four seconds. PCI DSS scope (dashed borders above) is limited to the AWS nodes that touch cardholder data. The credit scoring service on GCP receives a tokenized payload and never sees raw card numbers. The VPN branches run in parallel -- a slow telecom response does not block the bank response.
Simplified simulation of the production transaction path. Topology and latencies are representative.
Overview
Business Impact
What Went Wrong
max_connections limit. Queries started queueing, then timing out, and payment confirmations stalled for roughly eight minutes. The fix was a connection pooler in front of RDS and lowering the per-instance pool size.The second problem was slower: MySQL queries degrading over months. The transaction ledger table grew past 200 million rows and several queries were doing full table scans. The ledger lookup that checks whether a customer has an outstanding installment was scanning the entire table instead of hitting the composite index on
(customer_id, status, due_date). It had never been indexed because the table was small when the query was written. Adding the index brought the lookup from 1200ms to 3ms. I found six more queries in the same state and added slow-query logging with a 500ms threshold after that.The third was a VPN tunnel flap during a bank partner go-live. The IPsec tunnel dropped every 90 minutes in production -- a dead peer detection timeout mismatch. The QisstPay side was set to 30 seconds, theirs to 120. During low-traffic periods neither side sent keepalives fast enough. The bank network team took two weeks to acknowledge the issue. I worked around it with a cron that detected tunnel state changes and forced a rekey.
Lessons Learned
Slow queries are a deployment problem, not a DBA problem. The unindexed ledger lookup was not a mistake -- it was correct when the table had 10 million rows. The mistake was not having a process to catch it as the table grew. Slow-query logging with weekly review is trivially cheap and would have caught it months earlier.
VPN integrations with banks are infrastructure projects with a political timeline. The DPD mismatch was a five-minute config change on both sides. Getting the bank to make that change took three weeks. Every VPN integration I have done since, I insist on a shared parameter sheet signed off by both network teams before tunnel setup begins.
Technical Highlights
- Hybrid multi-cloud architecture across AWS ECS, GCP Cloud Run, and on-premise bare metal servers
- 17 microservices migrated from fixed-capacity infrastructure to autoscaling Cloud Run
- Single Terraform codebase managing both clouds with separate state per environment
- PCI DSS compliance maintained across AWS, GCP, and office network throughout my tenure
- Point-to-point IPsec VPN tunnels to banks and telecom providers for real-time credit scoring
- MySQL read/write replica topology -- primary handles transaction writes, replicas serve analytics and consumer reads
- Network segmentation with dedicated VLANs for cardholder data, internal services, and management traffic
- Encryption at rest with AES-256 for stored card data and TLS 1.2+ for all data in transit
- Centralized log aggregation with tamper-evident audit trails retained for 12 months per PCI DSS Requirement 10
- Automated vulnerability scanning with Nessus and quarterly ASV scans per PCI DSS Requirement 11
Frequently Asked Questions
Q: What were the security and compliance requirements for QisstPay?
The infrastructure had to comply with PCI DSS audits. This required strict VPC segmentation, implementing secure VPN tunnels with banking institutions, deploying a secure GCP Cloud Run setup for 17 microservices, and setting up centralized audit log collections.
Q: How was the database scaling managed for high transaction volumes?
I optimized MySQL on AWS RDS by deploying a connection pooler in front of the database, right-sizing pool allocations across forty Cloud Run instances, and adding composite indexes on customer installment lookups to eliminate full table scans across 200 million ledger rows.
Q: What was the outcome of the migration to Cloud Run?
By migrating the 17 microservices from virtual machines to containerized Google Cloud Run, I established automated scale-to-zero when idle, cut code deploy times by 60%, and significantly simplified microservices management.
Want results like this for your infrastructure?
I specialize in taking complex AI pipelines and cloud setups from concept to high-availability production. Let's discuss how to optimize your workloads, secure your environment, and reduce cloud costs.