Well-designed Microservices Considerations

One of the core benefits of developing new systems with microservices is that the architecture allows developers to build and modify individual components independently.

One of the important aspects while designing micsroservices is to define their size and boundaries. How to avoid making your microservices too small and tightly coupled.

Avoid Arbitrary Rules

When designing and creating a microservice, don’t fall into the trap of using arbitrary rules. If you read enough advice, you’ll come across some of the rules below. While appealing, these are not proper ways to determine boundaries for microservices.

Arbitrary Rule #1: A microservice should have X lines of code

Let’s get one thing straight: there are no limitations on how many lines of code there are in a microservice. A microservice doesn’t suddenly become a monolith just because you write a few lines of extra code. The key is ensuring there is high cohesion for the code within a service (more on this later).

Arbitrary Rule #2: Turn each function into a microservice

If you have a function that computes something based on three input values, and returns a result, is that a good candidate for a microservice? Should it be a separately deployable application of its own? This really depends on what the function is and how it serves to the entire system.

Other arbitrary rules

Other arbitrary rules include those that don’t take into account your entire context such as the team’s experience, DevOps capacity, what the service is doing, and availability needs of the data.

Five characteristics of a well-designed service

If you’ve read about microservices, you’ve no doubt come across advice on what makes a well-designed service. Much of it boils down to the principle of high cohesion and loose coupling. While sound advice, these concepts are quite abstract.

Characteristic #1: A well-designed service doesn’t share database tables with another service

When it comes to designing a microservice if you have multiple services referencing the same table, that’s a red flag as it likely means your DB is a source of coupling.

Characteristic #2: A well-designed service has a minimal amount of database tables

The ideal size of a microservice is small enough, but no smaller. And the same goes for the number of database tables per service.

Characteristic #3: A well-designed service is thoughtfully stateful or stateless

When designing your microservice, you need to ask yourself whether it requires access to a database or it’s going to be a stateless service processing terabytes of data like emails or logs.

Characteristic #4: A well-designed service’s data availability needs are accounted for

When designing a microservice, you need to keep in mind what services will rely on this new service and what’s the system-wide impact if that data becomes unavailable. Taking that into account allows you properly design data backup and recovery systems for this service.

Characteristic #5: It’s a single source of truth

The final characteristic to keep in mind is to design a service to be the single source of truth for something in your system.

To give you an example, when you order something from an eCommerce site, an order ID is generated. This order ID can be used by other services to query an Order service for complete information about the order. Using the pub/sub concept, the data that is passed around between services should be the order ID, not the attributes/information of the order itself. Only the Order service has complete information and is the single source of truth for a given order.

there are other considerations for larger teams.

Amazon is a perfect example of a large organization with multiple teams. As mentioned in an article published in API Evangelist, Jeff Bezos issued a mandate to all employees informing them that every team within the company had to communicate via API. Anyone who didn’t would be fired.

This way, all the data and functionality was exposed through the interface. Bezos also managed to get every team to decouple, define what their resources were, and make them available through the API. Amazon was building a system from the ground up. This allows every team within the company to become a partner of one another.

Source: Follow these practical principles to get well-designed microservices boundaries