Payments Backend at Scale
One backend serving Banking, Airlines, Travel and E-Commerce — different traffic shapes, same reliability bar.
TL;DR
- Role
- Senior Software Engineer — architecture & team lead
- Where
- Pine Labs
- Stack
- Node.jsExpressMongoDBCachingRate limiting
- Outcomes
- 50K+ DAU99.9% uptime50+ B2B clients
The problem
Four very different domains — banking, airlines, travel, e-commerce — needed to run on shared backend infrastructure without one domain's traffic spikes or failures affecting the others, while a 5-engineer cross-functional team shipped features across all of them.
Constraints
- 50K+ daily active users with a 99.9% uptime expectation
- Multi-domain modularity — domains must not couple to each other
- 50+ corporate B2B clients with integration contracts to honor
- Team throughput — architecture had to make five engineers faster, not slower
Architecture
Traffic from web, mobile and B2B clients hits an edge layer that owns authentication and rate limiting — one choke point, uniform contracts. Behind it, each business domain lives in its own module with its own boundaries, so airline traffic spikes can't starve banking. Reads are served cache-aside; writes go durable-first to the database and then invalidate the cache. Every service exports metrics to monitoring watching p99s and error rates. In the diagram, the blue packet is a cached read; the purple one is a write taking the durable path.
- read path — served from cache
- write path — durable first, then invalidate
- telemetry — p99s and error rates to monitoring
Hover or tap a component to see its responsibility.
Decisions & trade-offs
Modular domains inside shared infrastructure — over splitting into microservices per domain
Five engineers across four domains — module boundaries gave us isolation and independent reasoning without the operational tax of running a fleet of services.
Cache-aside with explicit invalidation — over write-through caching
The traffic is read-heavy. Cache-aside keeps the write path simple and makes the failure mode obvious: a miss is a slow read, never wrong data.
Rate limiting at the edge — over per-service limits
50+ B2B clients integrate against contracts. One enforcement point means one place to reason about fairness, quotas and abuse.
Results
- 50K+ DAU served at 99.9% production uptime
- Dev velocity up 20% and production bugs down 25% via architecture and review-process changes
- 100+ code reviews conducted; 5 junior engineers mentored
What I'd do differently
I'd automate load testing into the pipeline earlier — we validated capacity reactively before making it a routine, boring check.
Shared at pattern level — production metrics are real, implementation details are illustrative.