Why you should consider microservices when building an app

Why you should consider microservices when building an app blog banner
fb twitter linkedin

If you’re looking at developing an app, one of the big questions you need to consider is whether to use microservices or stick with a classic monolithic service. It’s a choice that often gets overlooked, but if made at the beginning could save your company a lot of time and money (given the right situation).

So what are microservices?

It’s the distribution of a monolithic service into individual, smaller components. Imagine a wedding. Instead of having a single vendor who is in charge of everything, you have a separate vendor for photography, a separate one for flowers, another one that does the catering, and another that provides video services etc. This way, you can pick and choose how important each aspect is to you, and budget accordingly. Overall, it decreases your dependency on any one particular aspect. Okay, maybe a wedding wasn’t the best example to use in this case, but you get the gist.

The best real world examples of microservices are large scale corporate platforms like Facebook or Netflix who serve millions of users daily. Their login/authentication process is probably separate from the photo uploading process, which is separate from the commenting/like process. Due to the sheer scale these companies are dealing with, it would be almost impossible for them to stick with a single monolithic system. However, that’s not to say that only tech giants like these should be using microservices.

For any organization looking to develop an app, there are a whole host of benefits microservices provide.

Why use microservices?

Higher scalability

It’s often difficult to tell early on which aspects of an app will be taking up the most bandwidth. If developed with microservices, you can scale each component separately, enabling you to take the first iterations, and any future iterations of your app to production quickly and efficiently.

Fault tolerance & security

If one component of the platform/app fails or is breached, you only lose that one component instead of the whole system. All other components of the system will remain functional, and secure.


The smaller the responsibility of a component, the faster it can perform because you can maximize the computing power by targeting the more optimal technology stack. For example, you will experience faster loading times as a result of not having one component eating up bandwidth of a different component.


Not every team member will have to be proficient with every aspect of the system since they are independant of each other. A new member of the team will only have to learn a certain aspect of the component they’re specializing in. This also frees up the hands of developers to multiple stacks of technology rather than one single stack (i.e. services can use different databases)

Running costs

The benefits of cost come from the scalability of a component without duplicating the entire system. If your app got a lot more users on the platform all of a sudden, you could scale each component as needed, whereas otherwise you would have to duplicate the entire system which would be a lot more costly.

When to use microservices?

Despite all the advantages listed above, utilizing microservices adds a layer of complication to the development process. It’s something you would need to dedicate resources to and you would have to worry about a smarter gateway, interprocess communication and service discovery. Imagine a master node that splits off into hundreds of smaller nodes (components). Each microservice would have to speak to a single, master hub so that the whole system could still work together, and you would need someone to build or utilize such a system.

Some factors to take into consideration include the time & budget allocated for your project, the type of app you’re trying to build, and how many users your app is trying to support. In my slightly biased opinion, I would recommend microservices as the way to go 8 times out of 10. It’s way easier to implement at the beginning rather than switching from a monolithic service a few iterations in and when your team gets used it, it takes significantly less time to get the ball of the ground.

The only time I would advise against developing microservices when you’re extremely tight on budget, and you’re trying to deliver an MVP (Minimal viable product) to test the market. In this case, you’re only trying to get a bare bones first iteration of the app out, so it wouldn’t make sense to develop microservices until further iterations or re-builds.

It’s not necessarily the right move in every situation, but it’s definitely 100% something to consider before you commit to building an app.