If you’re considering moving to DevOps and Microservices approach, you may encounter several challenges ahead of you. Not only you have to think different in terms of application development and operations, but also how you design your small components so it can be join into a full application.
Traditionally speaking, many developers uses database integration approach as a means to share data across all entities, in a very centralized fashion. Although this approach has its own advantages, it lacks the capability of scaling when the application starts to get requests from million of users. The solution in this particular case is to come up with specific vendor solution which can scale the whole data in different silos, generating more administration and increase of costs in the process.
This article will show you how to overcome a Foreign Key (FK) relationship, which it the most common way to link two entities at the database level. When you’re designing your application with microservices in mind the whole data layer must be attached to one single service. With that approach, creating new services and updating them becomes an incredible easy task.
Before analyzing a few scenarios, you must understand 2 concepts very common used in the microservices community:
Similar to the design of TCP/IP, changing the behavior of one layer should not impact a change in the layers next to it. Hence, designing your service as loose couple as possible will enable to easily maintain over time.
The whole point of having your application using microservices, it’s to enable fast changes and deploy it fast, without the need of change the other parts of the system.
The whole goal of keep things simple, to design software with a behavior be located in just one place. If parts of the same behavior are located in different places it us going to take more time to change as when there is a need to change to different microservices.
Hypothetically speaking, let’s consider two entities, which each one of them is dealing with a different table in the database. The Deal Table is connected to Customer Table by Foreign Key (FK), so whenever we need information about the deals of a single customer, a simple SQL join will do the job.
In order to transform the whole relationship into a service approach get rid of the FK. By doing this the service Deal will provide all the safeguards of a FK handling by our service Deal. In this particular case, every time a new request comes, we need to check if a deal does exist before providing a response to a customer.
Essentially, the service will be like this:
This radically approach brings us a one concerning question:
With an old approach, a simple SQL join will bring us both the customer and deal information. Now, we need to call two SQL in order to get the same result. Is the new approach slower because we need to make two SQL calls to gather same information ? The answer: YES.
However, the benefits in turning those entities into services are:
- The Deal table can be in different databases (or schemas) without impacting a single database when scale out kicks in.
- Maintenance in each service will done easily, once each table doesn’t relate to anything else.
- You may (if makes sense in your project) use different persistence technologies (such as NoSQL).
Keeping things loosely couple and high cohesive is not as simple and many argue. The whole idea of is to set the boundaries within our problem domain and ensure that the related behavior is in one place and communicates with other boundaries as loosely as possible.