Why We Delete Microservices Entirely Instead of Fixing Them

Last Friday at two in the morning, I was staring blankly at a Grafana dashboard in the Makati office. The inter-service call graph filled the entire screen. Twenty-three nodes. User authentication, notification dispatch, payment verification, log collection, various proxy layers. Our team is five people. Five people looking after twenty-three services.

I took a screenshot of that dashboard, posted it to Slack, and wrote, "Let's delete all of this."

The Disease of Manila Startup Backends

If you work in the Manila startup scene long enough, you start to see a pattern. When a team that just closed a seed round designs their backend, the first word they reach for is microservices. They spin up a Kubernetes cluster, lay down a service mesh, and attach an independent database to each service. Before the MVP is even out, infrastructure costs exceed 80,000 pesos a month.

I get why this happens. "Do you have microservices experience?" has calcified into a rite of passage in interviews, and every conference slide deck paints the monolith as the villain. Go to a meetup at a co-working space near BGC and you'll invariably find a team connecting services that get fewer than a thousand requests a day through Kafka.

I was no different. When I first designed the architecture at a fintech startup I joined two years ago, I did domain separation by the book. User service, transaction service, notification service, settlement service. It looked clean. On paper.

How We Ended Up With Twenty-Three

The problem is that services breed. When exchange rate lookups slow down in the transaction service, the answer becomes "let's split out an exchange rate service." When SMS and email logic diverge in the notification service, it becomes "let's separate by channel." Once you start splitting, there's no reason to stop. Every time a new service is born, the same routine repeats: define a gRPC interface, add a health check, clone the CI/CD pipeline, align the log format.

At some point, I was spending more time debugging inter-service communication issues than writing business logic. When one service timed out, three others would cascade down with it. Tracing the root cause of an incident meant cross-referencing logs from four services in chronological order. Every time a PagerDuty alert went off in the middle of the night, it took twenty minutes just to figure out which service was actually the problem.

The Work of Deleting and Merging

Here's what actually happened after I wrote "let's delete everything" in Slack. First, we measured inter-service call frequency over two weeks. Of the twenty-three services, fifteen averaged fewer than 500 calls per day. There was no reason for them to exist as independent services.

Over the course of two weeks, we merged the fifteen into three modules. Databases that had been split out separately were reorganized into schemas within a single PostgreSQL instance. What had been gRPC calls between services became function calls. With the network hops gone, latency dropped noticeably.

The most tangible change was debugging speed. A request now flowed from start to finish within a single process, so we could pinpoint the cause with a single stack trace. Incident response time for middle-of-the-night alerts went from twenty minutes to three. The fact that we could get a bit more sleep was reason enough to call it a success.

Infrastructure costs changed too. Once we cleaned up the separate containers and load balancers that had been running for each service, monthly cloud costs dropped by roughly 40%. At a startup, that difference is equivalent to one developer's salary.

I'm Not Saying the Monolith Is the Answer

The criteria for what should be merged and what should stay separate are straightforward. Does your team size and traffic pattern justify the separation? Five people operating twenty-three services is not justified. On the other hand, a service like payment processing, where regulatory requirements differ and deployment cycles need to be independent, should stay separate. We left eight of ours as they were.

The mistake I see over and over is that the decision to split services is driven not by technical necessity but by résumés and trends. I remember meeting a CTO at a meetup in Makati who said, "We're a monolith and things run just fine." The reaction from people around him was as awkward as if he'd made some kind of confession. That awkwardness itself is the problem.

Deleting services isn't admitting to technical debt. It's not a confession that the original design was wrong. It's returning to a structure that fits your current team size and traffic. I call it "deleting," but in practice it's closer to reassembling things into a more precise shape.

Next time you find yourself staring at a dashboard at two in the morning, count the nodes. Then compare that number to the number of people on your team.