This month we had some great new hires and we took our time to plan for our next iteration of the Digital Assembly Line. A new architecture was proposed and will be the base for our first fully-built Digital Assembly Line and its next iterations.
The current state
May was a very important month for the Engineering team!
In April we have decided to start working on our vision for the Digital Assembly Line 2 (or DAL 2.0) and May was the month we set out to start that project.
As our current architecture is tightly coupled with Slack (Slack is basically our frontend for everything), we operate a set of micro-services that were built around Slack's features and limitations.
Every line of code was written with Slack in mind.
Every data was structured around Slack objects.
Every part of the business logic was limited by what Slack exposes or not in their API.
Don’t get me wrong, I’m not saying that Slack is bad on what it does.
What I’m saying is that it is really hard to solve the real problem with such limitations. Mainly because you don’t actually own the data you share with third-party services and this implies that you will never have a totally predictable environment to work with.
Where we're going
In a greenfield project, everything is possible. Your current problems are irrelevant now, you’re free to imagine how things should be. Luckily, we had some incredible new hires last month and we were fully aware of all architecture problems we experienced during this last few years.
We invested around 3 engineers/week to discuss current problems and decide how our next architecture should look like and why.
We took time to try and predict our future problems, make sure our decisions are aligned with our vision and that they could adapt easily to different business models.
We’re building the 2.0 that will naturally evolve to the 3.0 and 4.0.
Technically speaking, for us, this means going for a multilayered architecture with well defined services and responsibilities.
We're fixing our current service approach, we're fixing how we handle data.
The Data Access Layer
Mimir is an internal service that handles all the data and models. Having this as a service will allow us to scale horizontally based on demand and also support eventual changes in our models without the hassle of propagating changes throughout other services.
The Business Layer
Business Loki is the layer that handles all the business logic. This layer abstracts all necessary mutations in our data by exposing only the necessary methods that our business relies on.
Presentation and Service Layers
Midgard, our frontend, is our main presentation right now. It will provide the interface for agents and managers that operate the Digital Assembly Line.
We also have other services that connect our clients to our business and are responsible for internal data processing. These services are horizontally scalable and are responsible for very specific tasks, like reading our assistants' emails, processing metrics, and generating the payment requests to our agents.
This last couple of months we used all the knowledge we collected so far to rethink everything.
We started building a better system in basically every way: architecture, business logic, data structure and service providers.
The new architecture is scalable to handle our data demands and flexible enough to follow pivots in our business model.
We're getting better at what we already do, we're also getting better in getting better.