Design Like a Monolith, Implement as Microservices

The monolith vs. microservices debate has been going on for over a decade. And it's still the wrong question.

Monoliths give you simplicity. One codebase. One schema. One coherent API. They're easy to design, easy to understand, and easy to navigate.

Microservices give you scalability. Independent teams. Independent deployments. Independent scaling. The only way to grow beyond a single team.

The problem is these two things seem incompatible. Do you pick simplicity and sacrifice scale, or pick scale and sacrifice coherence?

What if you didn't have to choose?

The case for microservices is well understood: autonomous teams ship on their own schedule. No coordination required is for deployment. Each team owns its domain.

But the case against microservices is equally strong, and it's usually about the same thing: the API surface.

When each team designs their service independently, you get APIs that reflect team structure, not consumer needs. The Users team exposes /users. The Orders team exposes /orders. The Fulfillment team exposes /fulfillment/status.

Each API makes sense in isolation. Together, they're a mess.

• Different naming conventions (userId vs user_id vs uid)
• Inconsistent error formats
• No clear relationships between resources
• Consumers have to integrate with five services to build one feature

API fragmentation is the cost of microservices, not the infrastructure complexity or distributed systems challenges.

In a monolith, the API is a single, coherent surface with one schema and one set of naming conventions. A consumer can navigate from users to orders to fulfillment without learning three different API styles.

This is good design.

The best APIs feel like a single, well-designed product — regardless of how many teams or services power them behind the scenes. Stripe's API feels like one product. It's not. But it feels like one, and that is the result of deliberate, unified design.

The monolith achieved this by accident: everything was in one place, so the API was naturally coherent. Microservices lost this by design: everything is distributed, so the API fragments.

GraphQL Federation was supposed to solve this.

Split the schema across teams and let each team own their subgraph. Compose them into a supergraph and provide the consumers with a unified API.

In practice, it works — partially.

The composition process merges schemas mechanically. It doesn't enforce design coherence. If Team A calls it shippingStatus and Team B calls it deliveryState, both end up in the supergraph. Composition guarantees correctness (no conflicts), not quality (consistent, consumer-friendly design).

The supergraph ends up reflecting team boundaries, not consumer use cases. Which is exactly the same problem microservices created with REST, just hidden behind a unified query layer.

The insight we keep coming back to is this:

Design should be top-down. Start with what consumers need. Create a coherent, well-named, relationship-rich schema. This is the "monolith" part.

Implementation should be distributed. Each team implements the fields they own. Independent deployments. Independent scaling. This is the "microservices" part.

The problem with traditional Federation is that it merges these two concerns. Each team designs and implements their slice. There's no layer where the overall API is designed as a whole.

With Fission and Hub , the workflow separates cleanly:

A product team, frontend engineer, or API architect works on the supergraph as if it were a single schema. They see all types, all fields, and all relationships on a visual canvas. They propose changes that make sense from the consumer's perspective.

"The user should be able to see their shipping eligibility. It should be a field on User, with clear sub-fields for express availability and estimated days."

This is API design. It's about the consumer experience, and it doesn't matter how many backend services are involved.

Once the design is approved, the architect assigns fields to subgraphs, and Fission handles the decomposition — propagating entity keys, pulling in type dependencies, and managing federation directives automatically. Each team gets a clear specification of what to implement and ships independently.

The supergraph is assembled from these implementations, but the design was done holistically.

Three trends are converging:

1. Organizations are scaling past the coordination threshold. 20 subgraphs? Informal coordination works. 100+ subgraphs? Without unified design, the API surface degrades fast. Every new team adds capability but also adds inconsistency.

2. AI agents are becoming API consumers. Agents need coherent, navigable schemas. A fragmented API surface that confuses human developers will completely break an agent's ability to reason about your capabilities . The quality of your API design directly impacts the quality of your agent outputs.

3. The platform engineering movement expects better. Platform teams are being asked to provide "golden paths" for development. A fragmented API surface is the opposite of a golden path. Unified API design is becoming a platform engineering concern .

"Should we use a monolith or microservices?"

Neither. Both.

Design your API like a monolith. Implement it as microservices.

This isn't a compromise. It's taking the best property of each architecture and combining them at the right layer.

The monolith's strength was never about having one codebase. It was about having one coherent design.

Microservices' strength was never about having separate APIs. It was about having independent teams.

You can have coherent design and independent teams. You just need to separate the design layer from the implementation layer.

That's what Fission and Hub do.

If you're navigating the monolith-to-microservices spectrum and want to see how this works, get in touch or watch the Fission webinar .

Frequently Asked Questions (FAQ)