0014 - Service Granularity¶
Date¶
2023-05-22
Status¶
Proposed
Context¶
We are using the terms microservice, miniservice, mesoservice, and monolith to refer to different levels of scope.
Microservices are services that house the logic for one and only one business behaviour. Microservices are able to be organised by any of the following:
- strict business behaviour/service (e.g. registration, login, save site, etc)
- entity (account, customer, project, etc.)
- technical concern
Mesoservices are services that house multiple related business behaviours. Monoliths are services that house many business behaviours and could/should perhaps be separated in future.
Decision¶
We are defining the above terms and choosing to prefer Meso-services by default.
They need to be at a scale where their name and other organisational elements make sense at a glance and where service boundaries are meaningful.
This default choice is balanced by:
- Microservices can be justified when there is real independent scale or organisational pressure to separate them.
- Monoliths can be justified for the implementation of tightly coupled behaviour or when the initial development cost of splitting the service would add more complexity than value.
Consequences¶
Meso-services will become the default scope for new services, because they allow a reasonable amount of related behaviour to sit together without the overhead and fragmentation of microservices.
This means that developers need to think deliberately about service boundaries and whether an existing mesoservice should absorb new behaviour, whether a microservice is truly warranted, or whether a temporary monolith is the safer move.
We expect this to produce more consistent naming, more coherent repos, and less accidental proliferation of ultra-small services.