Apr 18, 2018
Re: Architecture behind Scrum.ai
A more detailed, updated overview of the architecture
Checkout the previous story:
As you can see, we follow microservices architecture to emphasise on scalability and prevent system wide failure.
Let’s walk through the architecture bit by bit.
Main Service
This is the main service that will contain most of the logic on an abstraction level. We host it in the We also plugs our database to this instance, with some redundancies/replicas as needed as we scale. The Main Service will communicate mainly with the Queue Service, although we also tightly use KataPlatform API to enable Natural Language Understanding to our bot.
Queue Service
As we grow to a Software-as-a-Service product, we expect to receive many request at a time, and we don’t want to fail at this. So we will use a queue using Redis to enable us to publish/subscribe intra-service messages to this service in an asynchronous way.
Chat Channel Services
Following the adapter design pattern, we will abstract away many chat services API to consume and post our interactive messages. Each of this service will live on its own instances independent of each other. Then all of the messages event will be sent to the queue service and consumed by the main service to process, on which the reply will be sent back to the queue and consumed by these chat channel services.
Scrum Tools Services
As with the chat channel, we follow adapter design pattern and abstracts the scrum tools like JIRA and Pivotal Tracker. These services will mostly consume commands like task mutations from the queue service and execute the actions, although sometimes we need to get data that we don’t have in our database from these services.
And that’s it! As I’m still learning on this area, please do criticise the design in the comment!
