Extensibility refers to the ability of developers (original authors and future maintainers) to iterate on a service to respond to new demands or constraints. In monolithic or even service-oriented architectures, extensibility can become difficult when multiple functions share core business logic or other dependencies.
When developing a microservice, make sure that it is built and documented in a way that allows for the graceful introduction of new features or degradation of old ones. This can come in several formats:
- Exhasutive API documentation
- Detailed commit histories that explain why certain changes were made to the codebase
- Informative API responses that indicate why a request failed and suggest resolution paths
As core domain models grew and new features were introduced, our components became tightly coupled, and enforcing encapsulation made separation of concerns difficult. Continuous integration turned into a liability because deploying the codebase meant deploying everything at once. Our engineering team experienced rapid growth and scaling, which not only meant handling more requests but also handling a significant increase in developer activity. Adding new features, fixing bugs, and resolving technical debt all in a single repo became extremely difficult. Tribal knowledge was required before attempting to make a single change.