From Monolith to Microservices
How we got started with microservices

We started with just a few microservices, as we read that knowing when to create a new microservice is as much of an art as it is a science. With this in mind, we erred on the side of caution and only split out the obvious pieces first. We decided to keep our user, authentication, model metadata, alerts, and tenant management logic in a service and split out the following pieces into separate microservices:

inference ingestion

inference & metric retrieval

Inference ingestion was an obvious candidate for a new service because it could be easily decoupled from the rest of the platform, and it was something that we knew would have to scale horizontally to meet customer data load. We designed inference ingestion as a lightweight service that makes use of Kafka to ingest both streaming data and batch data. From here, it naturally made sense to create an additional service that was responsible for retrieving inferences and calculating metrics on these inferences. It was important to consider performance here and we knew that our choice of data store was crucial to our ability to serve up insights quickly. With this in mind, we were able to leverage the expertise of our data engineers to choose the right data store for our inferences and write the microservice that was responsible for retrieving inferences and calculating metrics. While our data engineers worked to build these microservices, the remaining backend engineers began tackling API design and the remaining product work. After designing our APIs and getting through the implementation of the user, authentication, metadata, alerts, and tenant management, it became evident that the alerting part of our platform was a good candidate for its own microservice. Below you’ll find a simplified diagram of the architecture we arrived at.
['Kelsey Kerr']
['Microservices', 'Go', 'Startup', 'Technology', 'Software Development']