For teams new to microservices, there is always a challenge of understanding what exactly makes up a properly-designed microservice. Quite often, they fall into the quagmire of making their microservices too big, too small, or too tightly coupled.
A couple of CTOs have shared their experiences through interviews, condensed into five fundamental principles of well-designed microservices.
Although these concepts can be quite abstract, high cohesion and loose coupling are needed for a well-designed microservice.
According to Chris McFadden, while designing a microservice, it’s a red flag for multiple services to reference the same table. To be clear, it likely means the database is a source of coupling.
It is really about how the service relates to the data, which is exactly what Oleksiy Kovrin, Head of Swiftype SRE, Elastic, said:
“One of the main foundational principles we use when developing new services is that they should not cross database boundaries. Each service should rely on its own set of underlying data stores. This allows us to centralize access controls, audit logging, caching logic, et cetera.”
Furthermore, Kovryn explained that if a subset of the database tables, “have no or very little connections to the rest of the dataset, it is a strong signal that component could be isolated into a separate API or a separate service.” He also went ahead to explain that Darby Frey, Co-founder of Lead Honestly, echoed this sentiment by telling him that, “each service should have its own tables [and] should never share database tables.”
The ideal size of a microservice is to be small enough, but not too small. And the same goes for the number of database tables per service.
Steven Czerwinski, Head of Engineering, Scaylr, explained during an interview that the sweet spot for Scaylr is, “one or two database tables for a service.”
McFadden also explained, “We have a suppression microservice that handles and keeps track of millions and billions of entries around suppressions. But, it’s all very focused just around suppression, so there’s really only one or two tables there. The same goes for other services like webhooks.”
When it comes to designing a microservice, it’s important to be clear about whether database access is required or whether it’s going to be a stateless service. With that being said, when processing terabytes of data for the microservice like emails or logs it will lead to a better-designed service.
The CTO of Algolia, Julien Lemoine, explained, “We define the boundaries of service by defining its input and output. Sometimes service is a network API, but it can also be a process consuming files and producing records in a database (this is the case of our log-processing service).”
Taking cognizance of what services will rely on this new service and the system-wide impact if that data becomes unavailable will allow a properly designed data backup and recovery systems for this service.
Designing a service to be a single source of truth for something in the system is the final principle.
For example, when something is ordered 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 either 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.
While there are a lot of complicated discussions surrounding designing microservices, these five basic principles above will guide microservices designs.
With your vision, coupled with the expertise of our developers, Charter Global will provide you with powerful IT, digital, consultancy, and business solutions. We will provide you with the same success that we have provided our customers over the past two decades.