Last November, an early-stage founder walked into our studio with an emergency. They had raised a $1.8M seed round six months prior. Their mobile app had 6,200 weekly active users.
Their monthly AWS bill was $14,280.
Their burn rate was accelerating, and the engineering agency they had contracted originally was asking for two more full-time DevOps contractors just to manage their Terraform manifests.
When we asked to see their architecture diagram, we were handed a 14-service Kubernetes topology: an Auth service, a Notification service, a Profile service, an Order service, a Recommendation service, two Kafka brokers, an API Gateway with custom Lua filters, and three Elasticache Redis clusters across three Availability Zones.
For 6,000 users.
The Microservice Tax Nobody Talks About
Startups don’t adopt microservices because they need them. They adopt them because resume-driven development is an epidemic.
Here is what was actually eating this founder’s seed capital every single month:
- AWS NAT Gateways and Inter-AZ Data Transfer: When Service A talks to Service B across availability zones in different subnets, AWS charges you on both ends. Their internal gRPC chatter was generating $2,400 a month in pure transit fees.
- Cluster Overhead: Each microservice had 2 replicas for high availability, meaning 28 containers plus DaemonSets for Datadog and Fluentbit. They were running eight
c5.xlargeinstances just to keep the cluster scheduler from throwing OOM errors during deployment rollouts. - Database Connection Pool Exhaustion: Each container opened its own connection pool of 20 connections to AWS RDS Postgres. With 28 containers, Postgres was spending 40% of its CPU time context-switching between 560 idle TCP sockets.
And the punchline? Their mobile app felt terribly sluggish.
Every single screen load in the app required the API gateway to fan out calls to four microservices, wait for three synchronous HTTP responses, assemble the JSON, and return it. The p95 response time was 640 milliseconds.
[Mobile App]
│ (180ms LTE latency)
▼
[API Gateway] ──► [Auth Service] (12ms)
│
├──► [User Profile Service] (24ms)
│
└──► [Order History Service] ──► [Internal Kafka Queue] ──► [Analytics] (310ms wait)
Total roundtrip: ~526ms - 740ms. On cellular: painful.The Collapse: Back to a Modular Monolith
We didn’t “optimize” their Kubernetes cluster. We deleted it.
Over a four-week sprint, we collapsed all 14 microservices into a single, clean Go backend binary (though TypeScript with Fastify would have worked equally well).
- Internal HTTP calls disappeared: Function calls inside the same memory space take nanoseconds, not 25 milliseconds of TCP handshakes and JSON serialization.
- Shared Transactions: Operations that used to require two-phase commits, saga orchestrators, and Kafka event reconciliation became a single SQL transaction:
tx, err := db.BeginTx(ctx, nil) if err != nil { return err } defer tx.Rollback() // Atomically deduct inventory and create the order in 4ms if err := createOrder(tx, order); err != nil { return err } if err := deductStock(tx, order.Items); err != nil { return err } return tx.Commit() - Connection Pooling Fixed: One single connection pool of 30 connections to a single managed PostgreSQL instance. Zero socket thrashing.
The Aftermath
We deployed the new monolith onto two redundant virtual machines behind a simple Hetzner / AWS ALB setup.
- Monthly Cloud Bill: Dropped from $14,280 down to $122.
- p95 Latency: Dropped from 640ms down to 48ms.
- Developer Onboarding: New engineers can run the entire backend locally with
docker compose up -d dbandgo run .. No Minikube. No Helm charts. No AWS credential gymnastics.
If your team is spending more time wrestling with Helm charts and CloudWatch alerts than building features your users actually want, you don’t have an infrastructure problem. You have an over-engineering problem. Let’s fix it.