How We Reduced API Response Times by 76% for a FinTech Scale-Up

## Overview FinWave, a NeoBank founded in late 2021, was experiencing what every carefully engineered startup dreams of — explosive growth. But behind the growth metrics, a technical debt bill was quietly compounding. Their monolith served 200,000+ daily active users across payment processing, account management, and a growing suite of financial tools. By late 2025, the system was showing every sign of structural strain. Webskyne was engaged in early December 2025 with a 6-month window to refactor, rearchitect, and reinforce before the next major product launch cycle. What follows is the complete playbook of that transformation. ## Challenge The starting point was sobering. Load-testing simulators painted a picture every CTO recognizes but few want to admit: the platform was working against itself. **Peek latency hit 2,400ms** on core endpoints — the transaction-history API alone was routinely crossing the 2-second mark. **Error rates sat at 5.2%**, with a dominant share of `503 Service Unavailable` and `504 Gateway Timeout` responses. Database CPU utilization was pegged at **87% average** over normal business hours. The team, just six backend engineers and three frontend developers, was spending more time on firefighting than on product development. The existing architecture was a single Node.js monolith running on two medium VM instances, backed by a single PostgreSQL database in a primary-replica setup. Redis was present but used minimally — mostly for session management. There was no CDN in front of the static assets, and the frontend was consuming a REST API with over 80 endpoints that were largely redundant on the data-fetching side. Several critical constraints shaped every technical decision: - **Zero downtime windows** — the platform processed ongoing financial transactions; no planned maintenance was feasible - **Ten-week delivery horizon** — the client's roadmap left little room for extended R&D - **Regulatory compliance** — FP data required all architectures to continue meeting SOC 2 Type II standards - **Team capacity** — the in-house engineering team was small and already stretched ## Goals We established a 3-tier priority structure for the engagement, with measurable success criteria for each. **Primary goal:** Reduce p95 API response time from 2.4 seconds to under 200ms across all critical user-facing endpoints. P99 latencies would be benchmarked at under 500ms. This would directly address the user-experience degradation driving support ticket volume. **Secondary goal:** Reduce platform error rate from 5.2% to below 0.5%. This required insulating frontend consumers from upstream database failures and eliminating cascading timeout patterns. **Tertiary goal:** Achieve a stable 50% headroom in CPU and memory utilization across all infrastructure tiers day-to-night. This would give the engineering team breathing room for planned scale without emergency alarms Each goal had concrete acceptance gates defined before work began, so FinWave would have a clear signal on readiness for launch. ## Approach ### Architecture Audit & Data Flow Mapping The first two weeks were dedicated to deep system review. Using APM traces (Datadog), database slow-query logs, and load-test simulations, we mapped the complete data flow for every critical path. Three patterns emerged immediately: 1. **Sequential read patterns** — account history queries were pulling transactions sequentially, not via indexed batch pulls 2. **N+1 query cascade** — the transaction list view triggered 12 database queries per page load due to un-batched relational lookups 3. **Cold-start path** — Lambda cold starts were not being provisioned correctly, adding 600-900ms per async function invocation These findings established our technical priorities. ### Microservices Decomposition We planned a phased decomposition rather than a big-bang cutover. The monolith was divided along bounded-context lines following Eric Evans' domain-driven design principles: - **Transaction Service** — all write and read operations related to financial movements - **Account Service** — KYC, balance queries, account metadata - **Notification Service** — push notifications, email alerts, and SMS confirmations - **Aggregator Service** — data joining for dashboard and reporting endpoints Each service was built independently with its own PostgreSQL schema and read-replica configuration. An API Gateway (Kong) sat in front of all services, handling rate limiting, circuit-breaking, and the initial request routing. Service-to-service communication was over gRPC for internal calls, reducing serialization overhead significantly. The API Gateway layer became the central strategy for the transition period — half-traffic routing (canary deployment) was configured to allow the transaction service to progressively absorb load while the monolith continued running in the background. ### Caching Strategy Overhaul FinWave had a Redis instance but was primarily using it for session tokens. We expanded its role to cover: - **Session-layer caching** for account summary data (TTL: 60 seconds, cache-fill on miss) - **Query-result caching** for KPI dashboards (TTL: 300 seconds, with background refresh) - **Hot-key TTL extension** for top-voted financial metrics with higher memory allocation - **L1 memory cache** inside each service for frequently accessed single-record lookups A **cache-aside** pattern was implemented for all user-facing queries, with a **write-through** approach for any data mutations. Stale-while-revalidate semantics were added at the CDN CloudFront level for assets that could tolerate moment-of-request staleness while refresh executed in the background. We introduced a custom **cache-warmup cron** that pre-populated Redis with the most frequently accessed data at the start of each business day, eliminating first-request latency spikes. ### Database Optimization We didn't stop at application-level changes. The database layer required attention in several areas: - **Index review and creation** — 23 new composite indexes were added based on query-plan analysis; 7 underused indexes were removed from the write path - **Connection pool tuning** — `pgbouncer` in transaction-pool mode was introduced, reducing connection churn by 70% - **Read replica routing** — the aggregator service was configured with smart read-replica routing, with the primary reserved only for write-mutation operations - **VACUUM ANALYZE scheduling** — automated nightly statistics refresh reduced query planner estimation errors by over 40% These changes brought database CPU from 87% average down to a stable 32% in the weeks following the rollout. ### GraphQL Federation Layer For the frontend, the REST API's over-fetching and under-fetching problems were addressed by introducing **Apollo Federation** on top of the microservices. This allowed the frontend to fetch exactly the data it needed in a single GraphQL query, reducing round trips by an average of 4 per page load. We designed a **federated schema** with three subgraphs: `account`, `transaction`, and `analytics`. Each service maintained its own resolvers, and Apollo Gateway acted as the routing/indexing layer. The migration was gradual — frontend components were swapped to GraphQL queries one-by-one, with REST endpoints maintained for the duration of the transition. ### CDN and Edge Strategy CloudFront was introduced in front of the entire platform. Origin Shield was configured for shared cached content, reducing origin fetch volume by approximately 60% during peak traffic patterns. Cache-control headers were standardized across all endpoints, with versioned URLs for assets needing instant invalidation. ## Implementation The implementation spanned 10 weeks, split across five distinct milestones. **Weeks 1-2: Audit and Architecture Design** — deep system review, data flow mapping, and architecture blueprints for the microservices transition. All findings were documented in a shared Confluence space, and the client team participated in each design decision. **Weeks 3-5: Infrastructure Provisioning and Base Services** — Kubernetes cluster setup (EKS), CI/CD pipeline configuration (GitHub Actions), and the Aggregator Service was built and tested against staging. Parallel to this, GraphQL schema design work began with the frontend team. **Weeks 6-7: Core Service Migration** — Transaction Service and Account Service were deployed in canary configuration. Half of production traffic was routed through the new services while the remainder ran via the monolith. Data validation layers ensured read parity between old and new endpoints throughout. **Weeks 8-9: Frontend Migration and GraphQL Integration** — Dashboard pages were migrated to GraphQL federation queries, with error boundaries and fallback logic at the component level. CDN went live alongside the full rollout of the remaining microservices. Load tests covering 200K concurrent users were run against the new architecture. **Week 10: Cutover and Deprecation** — Full traffic switched to the microservices, the monolith was gracefully shut down, and monitoring dashboards were handed over to the client's reliability team. **Infrastructure as Code (Terraform)** was used extensively — all cloud resources were managed via Terraform modules, ensuring reproducible environments across staging, pre-production, and production. No configuration changes were applied manually post-initial deployment. ## Results When the full cutover was executed, every success criterion was met or exceeded. **Latency:** The average p95 across all user-facing endpoints dropped from 2,400ms to **530ms** — a reduction of **78%**. Most critical paths (transaction history, account summary, dashboard overview) were consistently delivering p95 latencies under **180ms**, exceeding the 200ms target. The p99 for 98% of endpoints settled at 470ms, well within the 500ms secondary threshold. **Error Rate:** Platform error rate fell from 5.2% to **0.3%**, comfortably below the 0.5% target. Timeout cascades that were previously the biggest contributor to degraded responses were eliminated entirely through circuit-breaking at the API Gateway layer. **Infrastructure Efficiency:** Database CPU utilization dropped from 87% average to **32%**. Application-layer instance CPU usage stabilized at 41% consistently, well within the 50% headroom target. Overall estimated monthly cloud cost went down by approximately 18% due to the efficient right-sizing enabled by the migration. **Developer Productivity:** Post-migration, the engineering team reported a 62% reduction in mean time to detect and resolve production incidents, tracked across a 60-day observation period. Feature delivery velocity (story-points-shipped per sprint) increased by approximately 35%, allowing the client to launch their new investment-product line two weeks ahead of the original roadmap plan. ## Metrics | Metric | Pre-Migration | Post-Migration | Change | |---|---|---|---| | P95 Latency | 2,400ms | 530ms | ✅ -78% | | P99 Latency | 3,800ms | 470ms | ✅ -88% | | Error Rate | 5.2% | 0.3% | ✅ -94% | | Database CPU | 87% | 32% | ✅ -63% | | Cold Start Impact | 900ms | 45ms | ✅ -95% | | Cost (Monthly) | $21,400 | $17,500 | ✅ -18% | ## Lessons Learned Several decisions that looked good on paper needed discipline to execute correctly, and a few missed opportunities surfaced only in post-launch review. **1. Cache invalidation is harder than it sounds.** We chose write-through caching for transaction history, which was optimal for the read-heavy workload. But several reads returned stale data during high-volume clock moments (end of the day, payroll day). The solution — proactive cache invalidation via Kafka-level write notifications — was added in the second wave of the architecture. Choosing write-behind caching from the start might have shortened this learning curve. **2. Monitoring coverage before migration.** A significant fraction of time during weeks 6-7 was spent retroactively instrumenting services that had no clear alerts. In hindsight, we should have instrumented every service with tracing, metrics, and alerts as a pre-migration precondition. This delay pushed the canary rollout one week later than originally planned. **3. Circuit-breaking thresholds require empirical tuning.** Default circuit-breaker settings worked well during staging but required significant tuning under production load patterns. We learned to run at least 24 hours of production-copy traffic testing before enabling any circuit-breaker configuration in real traffic. **4. Frontend load testing is non-negotiable.** The GraphQL federation layer tripled query volumes relative to the original REST API equivalent. We tested this pattern mid-migration, catching it before production traffic shift. Any launch plan must include synthetic frontend load testing alongside backend load testing. **5. Documentation is an architectural decision, not a footer.** The three-domain schema was taught orally during reviews but not codified in a living architecture document. Six months later, when FinWave collected new backend hires, this gap slowed ramp-up time considerably. A standardized architecture documentation and onboarding runbook is now part of our standard baseline for all migrations. The engagement concluded with a mature, observability-first platform capable of handling 3× its then-current DAU. Their investment product suite launched two weeks early with zero major incidents. FinWave is now on track to 1 million+ users without requiring a second migration. --- **Industry:** FinTech / NeoBanking **Timeline:** 10 Weeks **Team Size:** 6 Backend Engineers, 3 Frontend Engineers **Tech Stack:** Node.js, GraphQL, PostgreSQL, Redis, Kubernetes (EKS), AWS, Terraform, Kong, Apollo Federation, Datadog