Picture a small online shop. One codebase, one database, one deploy. Customers sign in, browse products, pay, and get an email. It works, and for a long time nobody questions it.
Then the shop grows, and the questions start. Why does a bug in the product page force us to redeploy the payments code? Why does the whole application slow down every time someone uploads a batch of product photos? At some point, someone says the word: microservices.
This article follows that shop. We'll look at what microservices are, the guidelines that tell you when a feature deserves to become one, what you gain, and what it costs. We won't go deep on how to build them; that's a story for another day.
What Is a Microservice, Really?
A microservices architecture splits an application into small, independent services, each responsible for one capability of the system. Instead of one program that does everything, the shop becomes a set of programs that talk to each other, usually through APIs.
The key word is independent. Each service can be developed, deployed and scaled on its own. That independence is the whole point, and it's also what makes the decision hard: you only get the benefits if the pieces are truly separable.
So which pieces are? Let's walk through the shop and find out.
Which Features Deserve Their Own Service?
Not every feature justifies a service of its own. Here are six guidelines, each one showing up as the shop grows.
1. The Feature Can Stand on Its Own
Sign-in and payments are the first candidates. Neither needs to know how products are displayed or how orders are shipped. They take a request, do one job, and return an answer.
That's functional autonomy: if a feature can operate without being tightly coupled to the rest of the system, it's a good candidate. Authentication and payment management are classic examples.
2. It Needs to Scale Differently
Now the shop adds image uploads. Every product photo is resized and compressed, and during a big catalog import the servers run hot. But the checkout page doesn't need any more power than before.
Scaling the entire application to handle one heavy task is wasteful. When a feature has scaling requirements different from the rest, as an image processing service that needs a lot of compute does, a separate service lets you scale only what's under pressure.
3. Other Systems Need It Too
The shop starts a second brand with its own website. Both need to send order confirmations and password resets by email. Copying the email code into the second project would work, until the day one copy gets a fix and the other doesn't.
If several systems or applications use the same capability, turning it into a service encourages reuse and removes duplication. An email notification service is the usual example.
4. It Changes on a Different Rhythm
The team adds product recommendations powered by machine learning. The models are retrained and tweaked constantly, while the checkout flow changes a few times a year. Tying them to the same release cycle slows down one and puts the other at risk.
When a feature needs a development and deployment cycle different from the rest of the system, it should be its own service. A recommendation service that needs frequent updates is a good fit.
5. It Matches a Clear Business Domain
Look at how the business talks about itself: catalog, orders, payments, inventory. In Domain-Driven Design (DDD), these are subdomains, areas of the business with their own language and rules.
Features that map to a well-defined subdomain make ideal candidates. An inventory service in an e-commerce system, for instance, mirrors how the business already thinks.
6. It's the Right Size
Here's the guideline people forget. Imagine splitting the shop so far that "format a price" becomes a service. Every simple operation now requires a network call, and the system is a maze.
A microservice should be small enough to focus on one task, but large enough not to fragment the system excessively. If a feature is trivial, or depends heavily on others, it probably doesn't deserve to be a service.
What the Shop Gains
Suppose the shop follows those guidelines and splits out the right pieces. What changes?
- Scalability. The image service scales up during an import while everything else stays put.
- Technology flexibility. The recommendation service can use the language and tools best suited to machine learning, without forcing them on the rest of the system.
- Independent development and deployment. Different teams can work on different services at the same time, which speeds up development and continuous delivery.
- Resilience. Because services are decoupled, the failure of one doesn't necessarily take down the rest. If recommendations go offline, customers can still check out.
- Reusability. A well-designed service, like the email one, can be reused across projects and contexts.
- Easier maintenance. Fixing a bug or updating one service doesn't mean touching the whole application.
What the Shop Pays
If that were the whole story, every project would start with microservices. It isn't.
Splitting a system turns function calls into network calls, and a single codebase into many moving parts. The shop now needs advanced monitoring to see what's happening across services, careful versioning so one service doesn't break another, and a plan for how services communicate when things go wrong.
Those costs are real, and they land on you the day you split. That's why it pays to analyze carefully before turning a feature into a new service.
Back to the Shop
The shop didn't need microservices on day one. It needed them when specific features started pulling in different directions: different load, different release rhythm, different consumers. The six guidelines above are a way to notice that moment, and to notice when it hasn't arrived yet.
Used deliberately, microservices let a team focus on quality, scalability and agility. Used by fashion, they only add complexity. If you're still weighing the trade-offs, Modular Monolith or Microservices? A Framework for Deciding Without Dogma goes deeper into that decision.
Top comments (0)