Hello. Welcome to This Is My Architecture.
I am Antonio from AWS and today I am here in Milan with Alberto from Docebo.
-Hi, Alberto. -Hello, Antonio.
It is a pleasure to be here.
Alberto, tell us about what you do in Docebo.
Docebo is an e-learning platform designed for business education.
It is a modular system, it provides formal and informal training
and it is supported by AI services.
Ok. Today we are here to talk about this serverless architecture
made for the event management inside your learning-management system.
-Can you give us any details? -Absolutely. Our LMS microservices
need to communicate with each other
about these status changes of data.
Hence, we had to create a separate service
to manage these events.
We developed Eventbus which is divided into
a subscription module and a dispatching module.
I immagine the subscription module has an entry point in API gateway.
Then what happens?
The API gateway controls some lambdas to expose some endpoint rests.
The subscription of the microservices gets to the lambda
which processes the request and writes the subscription on a Dynamo DB.
Ok. Is Cognito used for the authentification part?
We use Cognito for the authentification part
because we had to
secure the intra-service communication, so all our microservices
use Cognito to exchange the JWT token.
So, through the API gateway, we use the authentification
through the token-Cognito request
to establish if a microservice can be subscribed or not.
Ok. So, once the subscriptions are saved in a DynamoDB table
I assume the microservices use SQS as entry point. Is that right?
That's right. If our microservices need to notify a status change
they write the event inside our main SQS queue.
This queue, through a SQS to lambda trigger, executes a lambda that
establishes which secondary queue the message needs to be written into.
So, the lambda reads the subscription from the DB Dynamo in order to decide
where the message is going to be written.
Ok. Once the messages are in these secondary queues, then what happens?
Kind of the same thing again. These queues, through a lambda SQS trigger
execute the lambda dedicated to that service queue which reads
through Dynamo which endpoint the message is going to be sent to
and then the message is delivered.
What if an error occurs during the delivering? What happens then?
Is the message lost or do you have a system for the error management?
We do have a system for error management.
If the lambda can't dispatch the message
the lambda puts the message in an error queue, a dedicated one.
This queue is awaken through CloudWatch by a lambda
which reads the messages
and rewrites them in the service queues
to try another attempt to send the message.
Ok. What is the main benefit you discovered in this architecture?
First of all, since this is completely serverless
there is the advantage of having full scalability.
We counted a load of about 20.000 messages per second.
This architecture can afford to maintain this load.
What was the development time?
Well, they were remarkable. I mean that it took very little
to develop this service.
Ok. Do you have any future developments in mind?
Yes, we do.
If we have bigger loads
we are thinking about replacing the SQS queue with a Kinesis.
The secondary queues, which have been considered generic
will be either SQS type
or DynamoStream type.
-Very interesting. Thank you, Alberto. -Thank you.
Thank you all for watching us on This Is My Architecture.