How to choose microservice architecture? Make your system run more stably

Have you encountered it? The system was fine when it first came online, but got stuck when there were too many users. Add a new feature and the entire system has to be retested. The team wanted to change something, but problems also occurred elsewhere. To be honest, many teams are facing this kind of trouble - the architecture they originally chose is now tied up.

What to do? Microservices seem like a good idea, but how to do it specifically?

To dismantle or not to dismantle? this is a problem

Some teams just pile all the code together and think it's that simple. Indeed, development was fast at the beginning, but after half a year, the code became a mess. No one dares to move casually because they don’t know where it will be affected.

Other teams are too broken up. A simple function needs to be called across five or six services, and to check the problem, you have to look at three or four monitoring panels. Deployment is even more troublesome. What could have been done in one day now requires the coordination of several teams.

It's like building Lego. If all the parts are glued together, you'll have to dismantle the entire building if you want to replace the windows. But if each part is too small to be seen, your hands will be sore when you put it together, and it will be easy to lose.

So how to dismantle it?

Find that "just right" point

A good microservice architecture is actually about finding a balance. It should be independent enough to allow the team to develop independently, but compact enough not to complicate simple things.

How to find this point? Look at the business itself. If a feature changes frequently, it should be a separate service. If a set of data always appears together, they should. For example, if user information, from registration to login to personal information, is split into three services, the interface will have to be adjusted three times each time the user page is displayed. Why bother?

But the order system is different. Placing an order is one process, payment is another, and shipping is another. These are completely separable because they change at different frequencies and have different teams responsible for them.

Did you know? Sometimes the hardest thing is not the technology, but the determination to unravel the code that has been entangled. It's like a garage that has been organized for many years. At first, I always thought "this might be useful", but in the end I was reluctant to throw anything away. But after you actually organize it, you will find that the space is larger and it is easier to find things.

Let the service members talk to each other.

Once it's taken apart, how can we communicate? There are two common ways: one is synchronous calling, like making a phone call, I call you, you have to answer it immediately; the other is asynchronous messaging, like sending an email, I sent it, and you can handle it at your convenience.

Synchronous calls are simple and direct, suitable for scenarios that require immediate response. For example, when checking a user's balance, you can't wait five minutes before the results are displayed, right? But it has a problem - if the called service hangs, the caller will also be stuck. It's like dominoes, one falls and then the other falls.

Asynchronous messages are more flexible. Services communicate through message queues, and the sender does not have to wait for the receiver to finish processing. Even if the receiving service is temporarily unavailable, the message will be waiting in the queue without affecting the sender. This is like going to the post office to send a letter. You can just put the letter in the mailbox and leave without waiting for the postman to pick it up.

But asynchrony comes with a price. The system becomes more complex, managing message queues and dealing with lost or duplicate messages. Sometimes you even need specialized services to track where a business process has gone.

Which one to choose? Depend on how much delay your business can tolerate and how much complexity you can accept. There is no absolute good or bad, only whether it is suitable or not.

What to do with the data? To divide or not to divide

Data storage is perhaps the toughest problem in microservices. The traditional approach is for all services to share a database. Simple, right? But the trouble is also here. Once the database structure is changed, all services may be affected. To make matters worse, services will be implicitly coupled through the database - if I change a field, how do you know whether it is being used?

The ideal state of microservices is that each service has its own database. In this way, services are truly decoupled, and changes in the database structure of one service will not affect other services. But here comes the problem: business data is naturally related. The order needs to know the user information, and the logistics needs to know the product details. How to synchronize these data?

There are two common methods. One is to obtain the required data through API between services, just like going to a neighbor's house to borrow something. The advantage is that the data is always up to date, but the disadvantage is that system performance may be affected if the call chain is long.

The other is data replication, where each service stores a copy of the data it needs. Just like you have tools at home, I also buy a set of the same tools. In this way, there is no need for frequent calls between services, but data synchronization has become a new problem - how to ensure that the data in my hand is consistent with yours?

kpowerWhen helping customers design architecture, we often recommend a hybrid solution: core data is independent, and shared data is synchronized through events. When user information is updated, the user service will publish a "User has updated" event, and other services that pay attention to this event will update their own stored related data. This maintains independence and ensures data consistency.

Operation and maintenance challenges—from complexity to simplicity

Microservices are indeed more complex to deploy than monolithic applications. Imagine that in the past, you only had to start one application, but now you have to start a dozen or even dozens of services. What about monitoring? How to check the log? How to quickly locate a problem when something goes wrong?

This is where good tools and processes are needed. Containerization technology makes deployment unified. Each service is packaged into a container image and runs the same in any environment. Orchestration tools help you manage these containers - automatically restart any container that fails, and automatically expand when traffic increases.

Monitoring is also layered. It depends on the overall system health as well as the performance of individual services. Link tracking is particularly useful. A request passes through five or six services. You can clearly see how much time it spent in each service and which step it got stuck at.

Log collection is just as important. The logs of all services are gathered together and searched using the same interface. Otherwise, when a problem occurs, you have to log in to seven or eight servers to check the logs respectively. By the time the problem is checked, the user will have run away.

In fact, the structure grows

Having said all this, you may be wondering: Which architectural pattern is best?

The truth is: there is no standard answer. The most suitable architecture should grow out of your actual business, rather than copying other people's designs.

At the beginning, you can start with a monolithic application, but you must consciously organize the code by business modules. When a module really needs to be developed independently, split it into microservices. Such gradual evolution is more practical and less risky than designing a perfect microservice architecture from the beginning.

kpowerThe team has been on many such journeys. From the initial lump of code to clear service boundaries; from manual deployment scripts to automated pipelines; from scrambling when problems occur to automatic system recovery. This process is like pruning a tree. Instead of cutting off all the branches at once, you can slowly trim them as needed to make the tree grow healthier.

Architecture is not the lines on the drawing, but the skeleton that supports the running of the business. It should be strong but not rigid; it should be flexible but not loose. When you find that balance, the system becomes alive—it grows, adapts, and remains stable despite change.

Isn’t this what we are pursuing? Let technology truly serve the business, rather than letting the business adapt to the technology. When architecture is no longer a problem that worries you every day, you can focus more on creating value itself. At that time, you may have forgotten the existence of architecture - the best architecture is often the architecture that people cannot feel.

Established in 2005,kpowerhas been dedicated to a professional compact motion unit manufacturer, headquartered in Dongguan, Guangdong Province, China. Leveraging innovations in modular drive technology, Kpower integrates high-performance motors, precision reducers, and multi-protocol control systems to provide efficient and customized smart drive system solutions. Kpower has delivered professional drive system solutions to over 500 enterprise clients globally with products covering various fields such as Smart Home Systems, Automatic Electronics, Robotics, Precision Agriculture, Drones, and Industrial Automation.