Microservice: Overcoming the Foreign Key Relationship

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:

Loose Coupling

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.

High Cohesion

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.


3 thoughts on “Microservice: Overcoming the Foreign Key Relationship

  1. Hi,

    Thanks for sharing this. We are actually little struggling with this foriegn key.

    Have a separate table for each objects is fine in your example, But there may be a chance based on the joined query I have to get the results.

    For example I have a permission table. And I need to make sure a certian user has permission to access certain deal.

    In such case how it can be handled in service layer? I might have three services like user service, permisson service and deal service. If a deal has to be fetched from deal service, then there must be some check agains the permission. How this can be handled in microservices architecture?



  2. Pingback: To Microservice or not to Microservice – helpful links and resources – Another Day in the Life of a Programmer Gal

  3. Quite interesting as I’m seeing the exact same discussion at my company where some architects are diametrically opposed to the DBA’s and some developers in this. While the logic makes perfect sense from a theoretical point of view, especially from a domain perspective, I seriously wonder about some aspects.

    1) The referential integrity is no longer enforced in all cases. There is no longer a hard constraint between the individual tables and as such you can easily work around the service and directly insert data into the table for example that will not be validated. And saying that this will never happen is an illusion.

    2) Performance. And this is the part that really bothers me. The effect will be minimal although definitely a slower than a foreign key for the case of one individual row where you do 1 call. But what about joining for example 500.000 records, which in database terms is peanuts? Will you do 500.000 calls to the service? Even when working in parallel I cannot see how this will work.

    I definitely see the logic behind this and I can see the advantages. But I’m not convinced this is the right approach. If you really want to get rid of foreign keys between schemas, I think there are database specific solutions that are better suited in my opinion.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s