4 Designing new features
This chapter covers
- Scoping microservices based on business capabilities and use cases
- When to scope microservices to reflect technical capabilities
- Making design choices when service boundaries are unclear
- Scoping effectively when multiple teams own microservices
Designing a new feature in a microservice application requires careful and well-reasoned scoping of microservices. You need to decide when to build new services or extend existing services, where boundaries lie between those services, and how those services should collaborate.
Well-designed services have three key characteristics: they’re responsible for a single capability, independently deployable, and replaceable. If your microservices have the wrong boundaries, or are too small, they can become tightly coupled, making them challenging to deploy independently or replace. Tight coupling increases the impact, and therefore the risk, of change. If your services are too large — taking on too much responsibility — they become less cohesive, increasing friction in ongoing development.
Even if you get it right the first time, you need to keep in mind that the requirements and needs of most complex software applications will evolve over time, and approaches that worked early in that application’s lifetime may not always remain suitable. No design is perfect forever.