A Serverless, Event Driven Architecture for Chatbots
In chatbot world, while your audience keeps growing, your processing time should stay the same. The processing time should not increase in direct proportion or exponentially with the number of users.
Event-driven architectures consist of events and event handlers. Event handlers are the subscribers for the events occurred in internal/external systems. In details, one event may have more than one event handler. And also, each event handler may create one or more events after processing the event data. Serverless platforms give the opportunity to implement highly scalable, event-driven architectures without pain.
Chatbot Credentials
Chatbot credentials (app id, secret, page tokens, etc…) can be saved to lambda env vars and retrieved when necessary.
Api Gateway and Auth
Whenever your endpoint gets a correctly signed data from a chat provider and it should return immediately one of the 200(ok), 201(created), or 202(accepted) HTTP status codes. If data is not signed correctly or signature is missing, good to return 403(forbidden) and do not move the data to SNS topic.
SNS Topics (Pub/Sub)
On every event, the event should be published to an SNS topic with the event inputs and outputs. Appropriate lambda functions should subscribe to the predefined SNS topics and process the data.
For example, after a successful authentication, the event data should be passed to the related SNS topic(or should be passed to Pub/Sub if you are using Google Cloud Platform).
Your topic subscribers(AWS lambda functions or Google Cloud functions) will process this data automatically. (The subscribers might be more than one.) Creating one cloud function for each small task, makes it more scalable and more event driven. For example; one for processing the input message, one for saving the whole input to DB and one for calling an external service.
Sending Messages To Chat Provider
When we need to send a reply message to the chat provider, this should be done using an another topic and a cloud function. And this function should be only responsible from hitting the endpoint and saving the result to an another topic. So, the result handler functions will be receive the request and response then make other operations like save, retry, notify and so on.
Message Handlers
Message handlers are platform specific handlers for different payloads(webhook payloads for FB messenger). These handler function may talk with internal, external services to prepare final output for the chat provider. And they deliver the messages to a conversation delivery SNS topic(‘response_prepared’ topic in the sample).
Service Functions
Service functions are platform independent core functions, that your chatbot needs to consume to operate properly. Separating the service functions will help you to implement multi platform chatbots easily.
DB Choice
Choice of DB is quite optional in serverless cloud. I recommend going with an option depending on later data usage, price and platform limitations.
Metrics
Metrics are the heart-beat of your apps and functions, and still they are in the serverless world. There are builtin metrics in serverless world like CloudWatch in AWS. Also another good thing is, if you are using Datadog to store metrics you won’t need external API calls, with AWS/GCP integrations you can save time.
Logs
In both AWS and GCP serverless platforms, logs are only one-click away to your architecture. And, you can set log retention, which function to log, what to log easily from cloud clients or from their web panels.
Preferring a serverless architecture might be a wise option if you want to keep your processing time like in the first day. Serverless solution is a cost effective scalable way to keep processing time in the same level while the number of users increases in time.
There are several cloud components to implement event driven architecture on serverless platforms. This proposal only covers AWS/GoogleCloud using Pub/Sub style event handling. This story might be considered as a serverless extension of my previous story about Backend Design/Architecture Practices for Chatbots. If you like the story, please click ♥️ or share to deliver it to more readers.
