Modular Design vs. Microservices: Which One Actually Helps a Business Scale?

As a company grows, one question shows up again and again: should the product stay together as one system, or should it be split into many independent services?

In business conversations, that question often gets simplified into a false choice. “Modular” sounds old-fashioned. “Microservices” sounds modern. But they are not opposites. In fact, they solve different problems. That is also the central lesson in Milan Jovanović’s video, “Why Shopify Rejected Microservices (And What They Did Instead),” which uses Shopify as an example of a company that chose a modular monolith rather than treating microservices as the automatic next step. Shopify’s own engineering writing says the company focused on turning its monolith into a modular monolith to maximize developer productivity, and later built tools to enforce boundaries inside that codebase.

For founders, managers, and operators, the more useful question is not, “Which architecture is more advanced?” The better question is, “Which structure helps the business grow without creating unnecessary complexity?” Shopify’s engineering team framed the problem in terms of productivity and system boundaries, not fashion, and described a long-running effort to make their large Rails monolith more modular through clearly defined components.

What modular design really means

Modular design is the practice of dividing a system into clear parts, where each part has a distinct responsibility. In plain business language, it means the software is organized more like a company with well-defined departments than like a pile of overlapping tasks. The goal is clarity: fewer entanglements, clearer ownership, and safer change. Shopify described this direction as creating “smaller, independent units of code” inside its monolith, which it called components.

That distinction matters because modularity is mainly about boundaries, not infrastructure. A company can have one codebase and still be highly modular if the major business areas are separated clearly and forced to interact in disciplined ways. Shopify’s Packwerk article explains that the tool was built to enforce boundaries between packages inside a large Rails application, specifically so large-scale domains within the monolith could interact through well-defined boundaries.

What microservices really mean

Microservices are a different idea. They are separate services that run independently, are often deployed independently, and usually own specific business capabilities. In the right environment, that can give teams more autonomy and make it easier to release changes without coordinating every deployment across the whole system. Shopify’s engineering posts indirectly highlight the contrast: their choice was not to fragment the system into many services, but to preserve the advantages of one codebase while improving boundaries inside it.

This is why microservices should be understood as an operating model, not a synonym for good design. They introduce real benefits, but they also introduce real costs: more deployment machinery, more monitoring, more coordination between services, and more opportunities for failures to spread across distributed systems. Even Jovanović’s own broader commentary outside the video emphasizes that many teams run into complexity problems before they run into true scaling problems, which is consistent with the Shopify example.

The mistake many companies make

Many companies confuse modularity with microservices. They assume that if they want clear separation, they must split everything into separate deployable services. That is often where the trouble starts.

The problem is that modularity is the goal, while microservices are only one way to pursue it. A company can have microservices that are still badly tangled because the business responsibilities are unclear. And a company can have a monolith that is modular, understandable, and productive because responsibilities are separated properly. Shopify’s own case is strong evidence for this: its engineers explicitly wrote about moving from “monolith” to “modular monolith,” not from “monolith” to “microservices everywhere.”

For non-technical leaders, this is an important mental shift. The real business win is not breaking software into smaller servers. The real win is reducing confusion, coupling, and coordination overhead.

Why microservices are so tempting

Microservices are attractive because they sound like a direct answer to growth. If the company is getting bigger, then surely the software should be split apart too.

That logic is appealing, but incomplete. Large internet companies made microservices famous, and that created a powerful narrative: successful companies use microservices, so ambitious companies should too. But large companies usually adopted them after reaching a level of scale, team specialization, and operational maturity that smaller firms do not yet have. Shopify’s engineering writing presents a different path: rather than defaulting to distributed services, it invested in modularity inside a single system to improve productivity as complexity increased.

The hidden cost is that microservices do not just divide software. They divide responsibility, operations, testing, release management, and incident handling. That can be worthwhile, but only when the business actually benefits enough to justify the added overhead. Otherwise, a company ends up paying for complexity it did not need.

What Shopify’s example teaches

The Shopify example is useful because it challenges a common assumption. Here is a very large and well-known technology company that did not treat microservices as the default destination. Instead, Shopify’s engineering team described a years-long effort to make its Rails monolith more modular, creating components aligned to domains such as Delivery, Online Store, Merchandising, and Checkouts. It then used Packwerk, a static analysis tool, to help enforce package boundaries and guide communication through explicit interfaces.

That choice says something important for managers: scale does not automatically require distribution. Sometimes the bigger issue is not raw traffic or system size. It is the difficulty of understanding and changing the product safely. Shopify’s own framing emphasized developer productivity and happiness, which is another way of saying that architecture should help teams move clearly and confidently, not just chase a trend.

This is why the Jovanović video is a useful reference point. It turns Shopify into a practical example of a broader lesson: many businesses should become more modular before they become more distributed.

The business case for modular design

For many companies, modular design is the more practical first step because it improves structure without forcing the organization to absorb the full cost of microservices.

A modular system is easier to understand. That matters because businesses change constantly. Pricing changes. Policies change. Customer workflows change. New products get added. When the system is modular, those changes can often be contained within a clearer business area rather than sending confusion through the entire product. Shopify’s component-based approach was explicitly intended to help the system scale in capabilities and complexity by creating smaller units with clearer domain boundaries.

Modular design also tends to lower coordination costs. Teams can still work within one broader system, but with fewer accidental dependencies between parts. And because everything is not yet distributed across many runtime environments, the operational burden stays lower. That can be especially valuable for startups, mid-sized firms, or companies still refining their business model.

When microservices do make sense

This does not mean microservices are bad. It means they should be used for the right reasons.

Microservices can make sense when domains are stable, teams are large enough to own services independently, release independence matters enough to justify the cost, and the organization already has the operational discipline to manage distributed systems well. In those situations, the benefits can be real: team autonomy, clearer service ownership, independent deployments, and stronger isolation between parts of the system.

But those advantages are not free. They come with added infrastructure and process complexity, which is why adopting them too early often creates more friction than progress. The Shopify example reinforces this by showing that even at major scale, a company may still prefer stronger modular boundaries inside a monolith over the immediate jump to microservices.

The practical takeaway for founders and managers

For non-technical leaders, the lesson is straightforward.

Do not treat microservices as a badge of sophistication. Treat architecture as an operating choice that should match the company’s stage, team structure, and actual business needs. If the business is still evolving quickly, if teams are still relatively small, or if the biggest pain is confusion rather than scale, then modular design is often the smarter priority.

In that sense, modular design and microservices are not really competitors. Modularity is the principle. Microservices are one possible implementation strategy. A company that lacks modular thinking will struggle even if it adopts microservices. A company that gets modularity right may be able to go much further before it ever needs distributed services. Shopify’s engineering history is one of the clearest public examples of that point.

Conclusion

The debate between modular design and microservices is often framed the wrong way. It is not a battle between old and new. It is a decision about where complexity should live.

Modular design tries to reduce complexity through clearer boundaries inside the system. Microservices can extend that idea, but they also export complexity into operations, coordination, and distributed communication. For many companies, the right move is not to rush into microservices. It is to build a system that is modular, understandable, and well-bounded first.

That is the deeper lesson behind the Shopify example referenced in Milan Jovanović’s video: the smartest architecture is not the one that sounds most advanced. It is the one that helps the business grow without becoming harder to run.

I can also turn this into a sharper publication-style version with a stronger hook and more opinionated executive tone.