SOLID / IDEALS - Microservice Design Principles
As developers, we build software and make decisions daily that can influence our code and the system’s design. Small changes in the code can result in bugs. For these reasons, we should follow SOLID Principles. And at the project level, the same thing can happen to result in a bad design and failures. We are making decisions at this level matter, especially with an ever-increasing number of tools, frameworks, platforms around microservices.
SOLID can help a developer to write better code. So what about the project level and application design? Some of the SOLID principles apply to microservices but don’t cover the whole spectrum of design decisions for microservices applications. Thus, the SOLID principles for microservices are IDEALS.
“DEALS” are core principles for microservice design:
- Interface segregation: tells us that different types of clients (mobile, web, CLI) should be able to interact with services through the contract that best suits their needs.
- Deployability (is on you): acknowledges that there are critical design decisions and technology choices developers need to make regarding packaging, deploying, and running microservices.
- Event-driven: suggests that services should use asynchronous messages or events instead of the asynchronous call.
- Availability over consistency: reminds us that more often, end users value the availability of the system over solid data consistency, and they’re okay with eventual consistency
- Loose coupling: remains a critical design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.
- Single responsibility: enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.
Following the IDEALS is not a magic elixir that will make a microservice design successful. As always, we need to have a good understanding of design patterns and architecture tactics.