Microservices: Divide to Scale

Around 2019, microservices went from being a conference topic to becoming mainstream. The big platforms told how they split enormous systems into small, independent pieces, and suddenly half the world wanted to “migrate to microservices.” The idea is simple and seductive: instead of one giant application that does everything, you have several small services, each responsible for one function, communicating with each other.

The problem is that most of those stories came from companies with thousands of engineers and millions of users. For a Mexican small business, copying that recipe to the letter usually means trading a problem you do have for three you don’t yet. The good news is that the underlying lesson—divide to scale—does apply to your business, as long as you know when to do it and how far to go.

What microservices are (and aren’t)

Imagine your system as a building. A monolith is a house where the kitchen, office, and warehouse share walls: practical at first, but if you want to expand the warehouse you have to touch the whole construction. Microservices are more like independent shops in a plaza: each one opens, closes, and grows on its own, connected by common hallways.

That independence is exactly what’s valuable. You can update the billing module without risking the inventory one, or give more resources to the part that receives orders during peak season without inflating everything else. But each “shop” also needs its own door, its own security, and its own maintenance: more pieces means more coordination.

Dividing a system doesn’t make it simpler; it shifts the complexity from inside the code to the spaces between services.

When it does pay to split

It’s not about trends, but about concrete pain points. It’s worth starting to split when you notice signs like these:

• A small change forces you to test everything. If touching the shopping cart makes you review even the accounting report, the system is too tightly coupled.
• One part grows much faster than the others. For example, the one handling traffic spikes or processing lots of data, and today it drags down the rest.
• Teams getting in each other’s way. When two people or areas can’t move forward in parallel because they’re editing the same thing.
• Different technical needs. A module that requires a specialized technology (payments, heavy reports, integration with a third party) and shouldn’t constrain the whole system.

If you recognize one or two of these symptoms, you may not need full microservices: it’s enough to split off that problematic piece and leave the rest alone.

When NOT to overcomplicate

For most small businesses, a well-built single-piece system is more than enough for a long time. Splitting too early has real costs: you need to manage more servers, monitor the communication between services, resolve what happens when one fails, and keep information consistent across several databases.

If your operation still fits comfortably in an orderly system, adding microservices “just in case” only adds infrastructure and time costs. In custom software we prefer to start with the minimum you can measure: build the monolith well, keep it clean, and split only when the business asks for it. That way you keep your data, processes, and history without gifting complexity to a future that hasn’t arrived yet.

How to split without over-engineering

If you think your system needs room to breathe, these steps will help you decide with judgment and without excess:

• Locate the real bottleneck. What part crashes, slows down, or holds back your team? Start there, not everywhere.
• Split a single module first. Extract the most problematic piece, measure it for a couple of months, and learn before continuing.
• Mind the boundaries. Define clearly what each service does and how they communicate, so you don’t create a tangle worse than the monolith.
• Think about your team, not just the technology. The division that helps most is usually the one that lets people work without getting in each other’s way.

Every business has its own sweet spot, and at Normandia Web we look for it calmly: sometimes the best decision is to divide to scale, and sometimes it’s to keep the system simple and well built. What matters is that it grows with you, with decisions based on reliable information and not on the trend of the moment. If you want, let’s talk about where that point is for your system.