Why I Slowly Killed Our Monolith

Anubhav Jaiswal — Thu, 07 May 2026 05:05:54 +0000

It was 2:00 AM. I was on my third coffee, staring at a terminal window that was doing that thing where it looks like it's working but isn't.

We were running a setup where every single customer had their own separate database space (a "schema"). On paper, it sounds like the perfect way to keep data isolated. In reality? It's a nightmare to manage. When the 401st customer's database hit a deadlock during a simple update, everything just stopped. I didn't have a big revelation right then; I just realized we had built a system that was eventually going to break us.

So we decided to move away from the monolith. Here's how we did it and what we learned.

The Bottleneck

Our original app was built with Python and Django. I love Django, but we had hit a wall. Python has a built-in limit on how many things it can do at the exact same time (the "GIL"). For a simple app, you never notice it. For us, with hundreds of people chatting, syncing files, and making API calls all at once, it was like trying to run a marathon while breathing through a straw.

We tried throwing more money at it—bigger servers, more power. It helped for a bit, but it didn't fix the underlying problem.

The biggest issue was that everything was connected. A slow query in a small, unimportant part of the app could suddenly make the login screen crawl. In a monolith, one fire in the kitchen eventually fills the whole house with smoke. You stop sleeping well when you know one tiny bug can take down everything.

The Switch to Something Simpler

We decided to move to Java 21. The main reason? A new feature called "Virtual Threads."

Before this, handling concurrency in Java meant managing thread pools — pre-allocating a fixed number of workers and hoping your traffic never spiked past what they could handle. When a thread was waiting on a database call or an API response, it just sat there, blocked, consuming memory and doing nothing. Under heavy load, we'd hit connection timeouts before we ever ran out of CPU.

Virtual Threads change that. Instead of a small pool of expensive OS threads, the JVM can spin up millions of lightweight virtual threads that are automatically parked and resumed while waiting on I/O. Crucially, you write normal, straightforward blocking code — no marking every function with "async" and "await" like a virus spreading through your codebase. It's like going from a 4-lane road to a 1,000-lane highway without having to change how you drive.

We went from constantly worrying about server limits at 1:00 AM to... well, not thinking about it at all. That was the real win.

Three Big Changes We Made

1. Cleaning up Identity
We stopped letting every part of the app worry about "who" the user was. We moved that to the front door (the Gateway). The Gateway checks the user's key once, attaches a simple tag to the request (like "This is Customer A"), and sends it along. By the time the request hits the actual code, the "Who is this?" part is already solved. It made everything feel much snappier.

2. One Big Table, Better Organization
We killed the "one database per customer" model. We moved everything into one big system but used partitioning to keep things organized. Every row of data is tagged with a Customer ID, so the database knows exactly where to look. The deadlocks vanished. Schema update jobs that used to crawl through 400+ separate databases now run in a single pass. What used to take hours dropped to minutes.

3. The "Piece-by-Piece" Move
I've seen too many projects fail because they tried to rewrite everything from scratch in one go. We didn't do that. We pulled out the most painful part first — the AI engine — and moved it to the new system. We kept the old app running for the rest. Over about seven months, we slowly moved features over one by one until there was nothing left in the old system. It wasn't flashy, but it was safe.

The Reality Check

Don't get me wrong — this isn't "easier." It's just "different."

Running several small services on your laptop is more annoying than running one big app. You have to deal with more configuration files, and it's easier to make a typo that breaks how the services talk to each other. That happened to us plenty of times.

You also have to think about "partial failure." In the old app, if it was up, it was up. Now, the login system might be working fine while the file storage is having a bad day. You have to build in safety nets so the user gets a helpful error message instead of just a spinning circle. We’re still polishing some of those edges today.

The Result

The best part? Friday deployments don't feel like defusing a bomb anymore.

I can fix a bug in the login system while someone else adds a feature to the dashboard, and we don't have to worry about stepping on each other's toes. The isolation is real, and it changes how the team works. We move faster because we aren't afraid of breaking the whole world with one line of code. Incidents that used to take down the entire platform now affect one service — and we catch them before most users ever notice.