The post is originally written here with code snippets as well -> https://easyontheweb.com/error-handling-in-microservices/

Recently I’ve been working on a microservices project on my own and have been taking help of some online tutorials (link at the end of the article) as well as this is like just my second or third microservices project. A couple of days ago I went through a module that covered error handling in microservices and I thought it was a really good one.

The strategies and concepts we discuss in this article are actually applicable to monolith applications as well but are super important when it comes to working with microservices based applications.

In this article we’ll see in brief what the difference between monoliths and microservices are, why error handling is so important in microservices architecture and also how we can accomplish a great strategy to handle errors.

Monoliths vs microservices
I’ve added this section in the article just to give a brief overview on what microservices are if some of the readers are unaware of them.

Basically, there are many architectures which are followed to create applications. Two of them are monolith and microservices. I’m pretty sure you’ll be aware of monolithic applications even if you don’t know about the term monolith.

Monoliths are applications that are what we can say – single. There is a single application and a single codebase for the entire application. The entire application is a big chunk that operates together. Microservices on the other hand are when different parts of the application are broken into separate, preferably independent services which work together to form an application.

Microservices contain different parts controlling and managing different parts of the application, say one part manages the authentication and the other part manages messaging or something.

Monolith applications have a single codebase whereas in microservices we have separate codebase for each service. You very well might think of each independent service as a separate app altogether!

A very interesting thing about microservices is that each service can very well be written using a different language, using a different framework and may even use a different type of database depending on the requirements for that particular service. This is what brings us to our next section…

The importance of error handling in microservices
Now that we know what microservices are, think why error handling is important in microservices ? As discussed before, the application is divided into various services that can also operate independently and even more importantly the different services may well be created using different languages and frameworks.

What you need to take care of is that even if there are different services handling different parts of the application, there is just one application that is being shown and used by the user. The frontend being served is a single application.

Think of it like this – we have a banking application with one service taking care of users, other taking care of the accounts and one taking care of transactions. But the user is using just one frontend application right? Therefore, all these services being used in the backend actually serve up to one service that controls the frontend – be it a browser for a web app or the mobile for an Android/ iOS application.

Let us assume that in this banking application – the frontend web application is written using React, the user and accounts microservices use express whereas the transactions service uses Ruby on Rails. Now, think about it – the errors in this application may be generated in any of the services right? But no matter which service the error gets generated in, the user always sees the error using our React frontend service.

Therefore, no matter which backend service gives rise to the error – the actual error handling and displaying has to be done by the service managing the frontend. This is where things can get messy. Suppose you have a different team of engineers working on the express applications and a different team on the Rails application – both these teams’ engineers will look to send errors to the React application in a format that suits their framework , or maybe just the default way their framework sends errors.

So, what shall be done on the React service ? Should the engineers on that team handle errors coming from express services differently and from Rails service differently ? I’d say that would cause a lot of trouble, wouldn’t it ?

The ideal solution is to make a particular format when you throw errors, no matter what service is throwing them – the engineers on the frontend service should always handle all the errors in the same way and not have to bother about where the error is coming from. What is important is that each error is taken care of the same way and this can only happen if the structure of every error coming into our frontend service is the same.

Which brings us to our next section on how we can do this ..

Error handling architecture in microservices
Now that we know how important error handling is in microservices let us see how we can maintain an architecture for the same. As I told, our job as an architect is to make sure that the engineers working on the frontend service do not have to take care of the errors on their part. They must always get a fixed structure when it comes to an error response, no matter from which service is it.

One way I like to structure my error responses is like this :-

Every error will be an object with the properties of message , meta and obviously the response will have a particular status code depending on the error type.

The message property is self explanatory and is just the message that we want to attach along with the error. More often than not the frontend guys will display this same message to the user when the error comes.

The second property is that of meta, which itself is an object and carries additional information on the error. The frontend engineers may or may not choose to use this additional info. , therefore it is totally up to them but as a backend service engineer, it’s our job to provide complete information on any error thrown by our service.

I’ve always found that these two properties are more than enough to display your error correctly on the frontend as well. You may choose to include another property called reason if you like but I generally keep that inside the meta itself. Your choice.

The main deal here is not what properties we send, the main thing is that we always send the same properties. The structure, no matter which service is throwing the error and not matter what kind of an error it is – maybe a validation error, maybe a database connection error, maybe a timeout of some sort – we must make sure that all the engineers working across different services agree on the structure of the error being thrown.

Let me give you a simple example of how we can modify all our errors and make them follow the same structure before sending them as response using express :-

error handling example in express
This is an example of a middleware that is written in Typescript (in the same tutorial that inspired me to write this article). To readers who work with JS or TS, we are doing nothing special here but taking two different kinds of errors and then modifying those errors and restructuring them in a way that the response being sent back is of the same format.

That is the key right ? Making sure that the response being sent back is following a particular format so that our frontend devs can take care of the errors easily.

I know that I’ve repeated the same things again and again many times in this article but trust me this is super important when it comes to structuring micro-services applications and this will eventually save you a hell lot of pain in the future.

Please check this course out on Udemy (a great course on micro-services with TS) => https://www.udemy.com/course/microservices-with-node-js-and-react/

For great resources to learn The MERN stack check this article out => https://easyontheweb.com/5-resources-to-become-a-mern-stack-developer/

If you’re active on facebook and want to join the easyontheweb facebook group here is the link for that => https://www.facebook.com/groups/503230450489995