Background 🔗
In most modern distributed architectures, two architectures designs are the most common: SOA (Service–Oriented Architecture) and Microservices (read more about their differences on this post from IBM). It’s normally a hard decision to whether keep adding functionality to a service or to break it into smaller microservices. There’s no clear line on where this division should happen. However, certain service characteristics can be major indicators that you should (or shouldn’t) break your service.
Indicators to break services 🔗
Do parts of the scaling need to scale differently?
If parts of the same service are required to scale differently, it should probably be broken up. Say, for example, a service that processes large files and performs a simple CRUD functionality. The CRUD functionality will most likely require way less memory and processing power (and pods under a Kubernetes context) than the file processing. However, if these functionalities belong to the same service, the simple CRUD will have to scale together with the file processing functionality. In addition, if the service goes down because of heavy load on file processing, the CRUD would also be compromised.
Are there errors that cause critical functions to fail within the service?
Is the service doing too many unrelated things?
Are changes isolated to only one part of the service?
Do some parts of the system need higher society levels than others?
Is the service always expanding to new contexts?
Indicators to keep services 🔗
Is an ACID transaction required?
If a service requires an ACID transaction, it should stay together. It’s not possible to perform an ACID transaction with multiple microservices (rather, you could perform a BASE transaction). Keeping the service together could ensure that if data is written to the Database it would be consistent. One example is an API that performs payment processing and it writes to multiple tables on a SQL Database. In some cases, like this one, data consistency is key to the functionality, and keeping the service together with an ACID transaction is critical.
Do services need to talk to one another? Network latency
Do services need to share code among one another?