How to split an application into services

Photo by Martin Sanchez on Unsplash

In software architecture we have terms such as monolithic applications, microservices, and even macroservices. But the truth is that if you ask ten people to explain each of these terms you will receive ten different answers.

There’s one thing we all agree on, however: applications tend to grow and sometimes they become too big and hard to maintain. It sometimes makes sense to split those applications into smaller ones (called services) that communicate with each other somehow.

But how to split an application? In how many services? How are they going to communicate? We don’t agree on these issues yet.

The first problem we have is that we don’t know what exactly constitutes a service. So here is my own definition:

A service is an application that can be deployed independently, exposes a well defined set of operations through HTTP or any other communication protocol, shares nothing with other services, and is (or will be) maintained by an independent team.

You can think of services as products that could eventually be offered to other companies as well. This means that each service should provide its own authentication mechanism for others to use it (usually in the form of API keys), API versioning, and good documentation!

Some services also expose a user interface (Web or mobile), and libraries that ease the integration into other Web and mobile applications, but user interfaces and integration libraries are not services per se.

An example

Imagine that you are developing an e-commerce application and it includes a recommendation engine and a support chat among other functionalities. Your team thinks that these two components can be extracted as services. How would you go about it?

Ok, so the first question is: does it make sense to create a service out of these components? Maybe the company is growing quickly and you now have a specialized data science group that will work on the recommendation engine, and a group to improve customer support, so it might make sense.

But here is the catch: why not use a recommendation engine or support chat from a third party? We could use AWS Personalize (or any alternative) as our recommendation engine and Intercom (or any alternative) as our support chat and knowledge base, for example.

There are still good reasons to create our own services. Maybe it’s the secret sauce of the company, or maybe our service will be so specific that we don’t find a similar thing in the market right now. But the important thing to note here is that you should think of your services as products that could be offered to other companies.

A checklist for a service

Here is a list of characteristics that make a good service:

  • Exposes a well defined set of operations through HTTP or any other communication protocol.
  • Shares nothing with other services
  • It is (or will be) maintained by a separate team.
  • Handles authentication in the form of API keys (e.g. private/public keys or JSON Web Tokens).
  • Provides versioning for the API.
  • Provides good documentation




Programmer. Constantly unlearning. Co-founder of (now and founder of

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Azure Boards — charts and Power BI

GHF Update 7/26/20 — Beginner Bundle, Dev Updates

How to Enhance Your Windows Batch Files by Adding GUI

Serverless Log aggregation and Error Monitoring Pipeline for AWS Lambda

Lifecycle of a bug

Using Ansible’s GCP Library to Provision a Kubernetes Cluster in Google Cloud

Introduction to Message Queue with RabbitMQ example

CQRS in a nutshell

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Germán Escobar

Germán Escobar

Programmer. Constantly unlearning. Co-founder of (now and founder of

More from Medium

Application Frameworks- NoSQL and Git

Implementing Domain-Driven Design

Event Driven Apps : Lost the Event??

Monolith vs Microservices architecture: Split or not to split?