12 principles of microservices design

When servo motors meet microservices: Why do traditional mechanical designs become cumbersome?

Imagine you are assembling a complex robotic arm. Each joint is controlled by a servo motor or servo, which is responsible for precise position, speed and torque. Everything is designed with rigor and precision - at least on paper. But when you start debugging, problems arise: a motor parameter adjustment requires recompiling the entire control program; a small sensor failure causes the entire system to shut down; you want to upgrade one of the modules, but find that it is tightly coupled with five or six other modules.

Sound familiar? It's like trying to carve a detailed sculpture out of a boulder. Every move of the knife may cause unexpected fragmentation. In the field of machinery and automation, we often fall into the dilemma of this "monolith architecture": the system is huge, rigid, and affects the whole body. Changing one part may mean redesigning half the machine.

Why is this happening? Maybe it’s because we are used to vertical, integrated design ideas. We package all the functionality—motion control, logic processing, communication protocols—into a tight block of code or hardware module. It used to be efficient, but when projects become complex and requirements iterate rapidly, this structure becomes a burden.

Is there a way to build our control system like building blocks? Let each servo motor or execution unit be like a small independent team, each performing its own duties while being able to communicate easily?

Enlightenment from microservices: dismantle mechanical systems into “intelligent cells”

This may sound a bit crossover, but let’s look at a hot concept in the software world: microservices. Simply put, it breaks a large application into a series of small services. Each service focuses on one thing and communicates in a lightweight way. You can develop, deploy, and extend any of them independently without affecting the whole.

How about mapping this into our mechanical and motor control projects? Picture this: you no longer have one central brain controlling all twelve joint motors. Instead, each servo motor (or each group of motors working together) is assigned a lightweight, dedicated "decision-making unit." This unit is only responsible for this motor - reading its encoder feedback, performing PID closed-loop control, and managing its temperature protection. It tells its neighbors through a clear protocol (such as CAN bus or EtherCAT): "My position is in place and the torque is normal", or "I need to slow down and the load suddenly increases".

This is the embodiment of the "microservice" design idea at the hardware and embedded levels.kpowerAfter deeply exploring this concept, a set of “12 Principles of Microservices Design” suitable for mechatronics projects was refined and implemented. It is not a ready-made product, but a set of design philosophy and construction patterns that help you break that "monolith" into "intelligent cells" that work in coordination.

What specific pain points does it solve?

• Changes are no longer scary: Want to optimize the response algorithm of a certain servo? You only need to update that small service without touching the entire core program, which greatly reduces the risk of testing and regression.
• Failures are isolated rather than diffused: An abnormal reading from a sensor will only affect the local service to which it belongs. Other parts of the system can be degraded or safely suspended, rather than completely crashing.
• Technology selection can be more flexible: The service responsible for communication can use one language, and the service responsible for motion planning can use another. You can choose the most appropriate tools and technology stack for each small module.
• Expansion becomes natural: Need to add a visual recognition module to guide the robotic arm? Just add a new service "building block" that follows the same communication rules without having to refactor the foundation.

From philosophy to practice: How to implement the 12 principles?

These 12 principles range from boundary delineation and independent deployment to fault tolerance and monitoring. Let’s talk about a few of the most intuitive ones.

For example, "single responsibility". This requires each microservice (corresponding to our project, which may be each motor control unit and each IO management module) to do only one thing. Just like a good steering gear, its responsibility is to accurately turn to the specified angle and maintain it. It should not calculate the trajectory of the entire path at the same time. Clear boundaries of responsibility are the starting point for reliability.

Another example is “decentralized data management”. Traditional systems may store all data—motor parameters, position records, alarm logs—in a central database. Microservice design advice: Let each service manage its own data. The motor control service keeps its own calibration parameters and operation logs; the communication service manages its own message queue. This reduces single points of failure and avoids infinite expansion and coupling of data structures.

Some people may ask: "With more services, won't communication become more complicated and slower?" This is a good question. This leads to the principle of “smart endpoints and dumb pipes”. The communication pipe (bus or network) should be kept simple and reliable, responsible only for transmitting data. All "intelligence" (such as data validation, business logic) should be placed in the services at both ends of the communication. This means that you need to carefully design the interface protocol between services to make it clear and stable enough.kpower, provides a large number of proven interface patterns and practices to balance the freedom and complexity here.

There’s also “fault-tolerant design.” In distributed systems, failures are the norm. A service failure, communication delays, and temporary data inconsistency may all occur. Our designs anticipate this. For example, when a motor control service is temporarily unresponsive, what should the upstream path planning service do? Should you wait, try again, or switch to safe mode? Defining these policies up front makes the system more resilient.

A journey, not a panacea

The introduction of this microservice-based design thinking is not to pursue technical fashion. It is essentially a response to the problem of complexity. When the project you face is no longer a simple three-axis platform, but an automation system that needs to coordinate dozens of actuators, interact with multiple devices, and has evolving needs, you will naturally feel the constraints of the traditional architecture.

kpowerThe "12 Principles of Microservices Design" framework is designed to help engineers and project leaders start this journey more smoothly. It provides a roadmap, a list of design patterns, and a guide to avoid pitfalls, rather than an enforced specification. You can start with a small module and try it, such as logging or alarming functions as a service, to experience the isolation and deployment flexibility it brings.

Ultimately, the goal is not to make the system "more distributed," but to make it more adaptable to change, easier to understand, and more robust and reliable. Just like a set of well-designed modular mechanical parts, each part is standard and strong, but when combined together, it can complete an extremely complex dance.

When starting your next mechatronics project, maybe ask yourself: Are we designing a heavy boulder, or a set of LEGO bricks that can be reconfigured and upgraded at any time? The different answers may define the future of the entire project.

Established in 2005, Kpower has 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.