What are the most essential microservice design principles?

Single concern

Dedicate the entry points into a microservice to a single purpose. For example, let's say a car trading organization wants to build an application that connects prospective traders with each other and the organization itself. One microservice component will deal exclusively with exchanging cars either by buying, selling or trading them. It has no other purpose.

Car payments are the focal point for another component in the overall design. While the two microservices may be used in conjunction with one another, the services aren't blended. Each element handles something different and can stand alone.

Discrete

Another term for this microservice design principle is well encapsulated. All logic and data that a microservice requires to do its work are internal and isolated from other microservice components.

While a microservice will most likely require its own configuration for the internals to operate properly, this configuration shouldn't interfere with the configuration of another microservice. This microservice design principle is particularly important when developers need to scale up or down to accommodate load demands.

Carries its own data

Not only should a microservice carry its own data, but its data should also remain independent of all other microservice components. In some cases, a microservice will ideally have its own database. In others, the microservice will share a database with others, but each microservice will have its own tables within the database.

Typically, developers use database sharing to reduce costs. However, this violates the spirit of the microservice design principle.

Developers often must consider both data independence and redundancy in their designs. While developers often support the principle that each microservice carries its own data can result in data duplication at the application level, they have also come to accept data redundancy as part of their microservice design pattern.

An easy way to understand accommodating data duplication among various microservices is to consider customer data stored at various online retailers. For example, a given user might be registered with Amazon and Walmart. Both websites will have a duplicate of that user's data, but each website is discrete and well encapsulated. Thus, neither website knows about the user's existence on the other website unless it's granted permission to that website's data.

Transportable

When a microservice is transportable, it means that it can be "packaged up" into a deployment unit -- such as a container image or a serverless function -- and deployed at any time to a given target via a CI/CD process.

For example, a developer can deploy a transportable microservice to a cloud provider such as Google Cloud at one moment. However, if a situation arises where the microservice needs to be deployed to a different provider, it shouldn't take more than a little effort for a developer to transport the microservice to AWS.

Ephemeral

An ephemeral microservice means that it can be destroyed at any time and then resurrected to its last known state immediately.

The ephemeral nature of a container has implications not only for how to manage application state when a given container could go offline at any moment, but also has implications on how to manage active threads and ensure thread-based dependencies don't exist in the code.

These five microservice design principles should be at the heart of any architecture discussions. Consider each element carefully to create an architecture that works efficiently for your application.