Megaservices

I’ve been thinking a lot lately about how much overhead modern software architectures and infrastructure create. It gets especially expensive in an era where apps can be built in five minutes using a coding agent. The industry default is to reach for microservices or serverless almost automatically. I wanted to do a thought experiment: what if we did the exact opposite?

What if, instead of a constellation of small services, you had one big service for multiple applications, each with their own purpose, UI, and logic — but all running off the same foundation? Same codebase. Same runtime. Same deployment process.

This idea is not new. A similar concept is multi-tenancy — nowadays often used in Kubernetes clusters or large database clusters. But the concept of megaservices is a bit more holistic. It’s closer to what we were doing back in the 90s: we had J2EE application servers hosting different applications. Would a similar architecture be useful today?

When you share infrastructure across apps, you get a lot out of the box: code repository, build system, authentication, logging, monitoring, CI/CD, runtime config, deployment environments. You don’t need to reinvent the wheel for every app. It’s great for fast prototyping, and even better for teams who need to build lots of small apps that don’t justify standing up a whole stack of complex infrastructure each time.

When This Makes Sense

This architecture could work best for:

• spinning up new internal tools or admin dashboards
• quickly prototyping ideas without wrangling infrastructure
• many small apps that share the same user base and data

I like to think of it as a kind of “app incubator.” It’s where ideas start. They may stay there, or they may eventually grow out of the nest and get their own dedicated service.

When It Doesn’t

There are definitely limits. This setup isn’t a good fit for:

• highly sensitive or regulated data
• the core business domain
• anything that needs to be independently deployable, isolated, or scaled

The more mission-critical an app becomes, the more you probably want separation — both for security and maintainability.

The Downsides

You pay for simplicity in other ways. A few real trade-offs:

• Dependency hell: If each app wants different versions of the same library, things get messy fast. You’ll need a governance process or some technical solution for incorporating multiple versions of the same library.
• Tech stack upgrades: Updating core libraries or runtimes affects every app at once. Nowadays you can leverage AI coding agents, so migrating several apps at once is less scary.
• Coupling: It’s easy for apps to start depending on each other in ways that aren’t obvious. Techniques from Modular Monoliths may prove useful.
• Startup cost: As the service grows, so does boot time, test execution time, CI duration, and complexity in onboarding new devs. You need governance and budgets for each of these things.

Scaling and Reliability

Despite being a monolith, this architecture can still scale: you can always run multiple instances of a monolith backed by a database cluster. Same goes for fault tolerance: you can run replicas.

The dimension where it doesn’t scale is complexity. As the complexity of the apps grows, this architecture starts becoming a mismatch and it’s time to extract the application in question.

Leaving the Nest

So how could we extract an app?

1. Clone the repo
2. Delete the other apps
3. Replace secrets, keys, and URLs
4. Change the tech stack if you want

Now it’s your own standalone service. You don’t need to untangle dozens of shared services — just copy what worked and leave the rest.

Final Thoughts

This isn’t a silver bullet. It’s not the right choice for everything. But for a certain kind of problem — building lots of small apps quickly and cheaply — it has potential. And the trade-offs are manageable if you’re intentional.