This document provides an outline for building a chatbot. It discusses key principles such as ensuring messages are processed and delivered in the proper order, minimizing dropped messages, and scaling the bot through techniques like using multiple message queues and consumer processes. It also emphasizes making the chatbot dynamic by defining states and transitions that can be triggered by rules, events, or user responses. This allows the chatbot's conversation to adapt based on factors like the user, previous responses, or external events.

1. How To Build A
ChatBot
By Himanshu

2. Chat: Types
Peer to Peer
● WhatsApp
Bot
● JobFinder

3. Chat: Types
Peer to Peer
● WhatsApp
● Message Processing?
○ Detect Intent for Spam, Abuse or Hate.
Bot
● JobFinder
● Message Processing?
○ Detect Intent to understand the
message. .

4. Chat: Types
Peer to Peer
● WhatsApp
● Message Processing?
○ Detect Intent for Spam, Abuse or Hate.
○ No validation or verification.
○ Ideally takes less time.
Bot
● JobFinder
● Message Processing?
○ Detect Intent to understand the msg.
○ Validation & Verification required. May
include API calls.
○ Major bottleneck in scaling the bot.

5. Chat: Types
Peer to Peer
● WhatsApp
● Message Processing?
○ Detect Intent for Spam, Abuse or Hate.
○ No validation or verification.
○ Ideally takes less time.
Bot
● JobFinder
● Message Processing?
○ Detect Intent to understand the msg.
○ Validation & Verification required. May
include API calls.
○ Major bottleneck in scaling the bot.
Message order should be preserved and Message drop be minimal

6. Chat: Client-Server

7. ChatBot: Outline

8. Till Now..
1. How does a chat application differ from a regular application with respect to
client and server communication?
2. How is a chatbot different from a peer to peer chat?
3. Basic Outline of a chatbot.

9. Principles: Messages In Order
Clients Bot Server
M23 M22 M13 M12 M21 M11
R11 R21 R12 R13 R22 R23
M23 : 3rd message by 2nd client
R21 : 1st reply for 2nd client

10. Principles: Messages In Order
Clients Bot Server
M23 M22 M13 M12 M21 M11
R21 R11 R12 R13 R22 R23
M23 : 3rd message by 2nd client
R21 : 1st reply for 2nd client
Order not to be preserved for
messages from different users

11. Principles: Messages In Order
At both client and server side we need
Queuing Mechanism
● Rabbitmq at server side
Acknowledgement/Receipts Logic
● Socket events

12. Principles: Messages In Order
At both client and server side we need
Queuing Mechanism
● Rabbitmq at server side
● Without it at client side:
○ Client’s 1st msg is a 5 mb image and
,within 2 seconds, one word msg is sent
as 2nd msg.
Acknowledgement/Receipts Logic
● Socket events

13. Principles: Messages In Order
At both client and server side we need
Queuing Mechanism
● Rabbitmq at server side
● Without it at client side:
○ Client’s 1st msg is a 5 mb image and
,within 2 seconds, one word msg is sent
as 2nd msg.
○ OR don’t give the option of sending a
msg till last one is delivered!!
Acknowledgement/Receipts Logic
● Socket events

14. Principles: Messages In Order
At both client and server side we need
Queuing Mechanism
● Rabbitmq at server side
Acknowledgement/Receipts Logic
● Socket events
● Without it at client side:
○ Network Latency for a bigger msg may
deliver a smaller one before it.

15. Principles: Minimal Message Drop
At both client and server side we need
Queuing Mechanism
● Rabbitmq at server side
Receipts & Retry Logic
● Socket events

16. Principles: Minimal Message Drop
At both client and server side we need
Queuing Mechanism
● Rabbitmq at server side
● Why?
○ Socket connection breaks.
○ User goes offline or server is down.
Receipts & Retry Logic
● Socket events
● Why?
○ No Receipt means msg needs to be
retried.

17. Principles: Minimal Message Drop
At both client and server side we need
Queuing Mechanism
● Rabbitmq at server side
● Why?
○ Socket connection breaks.
○ User goes offline or server is down.
● 30-40 percent drop because of
break in connection.
Receipts & Retry Logic
● Socket events
● Why?
○ No Receipt means msg needs to be
retried.
● 0.1-1 percent drop without retry
logic.

18. Scalability and Resilience
● Use multiple queues and multiple consumer
processes. Same client messages should be in the
same queue: Kafka Topics & Partitions, Rabbitmq
exchanges & routing keys
Messages of
two users
don’t put any
dependency
on each other

19. Scalability and Resilience
● Use multiple queues at server side and multiple
consumer processes. Same client messages should
be in one queue.
● If message processing fails for a particular client,
dequeue all messages for the same client and put in
another queue: Dead Letter queue.
Messages of
two users
don’t put any
dependency
on each other

20. Scalability and Resilience
● Use multiple queues at server side and multiple
consumer processes. Same client messages should
be in one queue.
● If message processing fails for a particular client,
dequeue all messages for the same client and put in
another queue.
● Message Processing Time should be kept in check:
Asynchronous API and DB calls wherever
possible.
Messages of
two users
don’t put any
dependency
on each other

21. ChatBot: Make it Dynamic
Greeting
Introduction
Last Content
Main Flow 2
Main Flow 1
Thank You
Human Interaction
Old User New User
Cohort 1 Cohort 2
Event X
Flow Added Later
Invalid UR

22. ChatBot: Make it Dynamic
1. Define states.
2. Define Transitions.

23. ChatBot: Make it Dynamic
1. Define states.
2. Define Transitions.
a. Based on Rules
b. Based on Events
c. Based on Responses

24. ChatBot: Make it Dynamic
1. Define states.
2. Define Transitions.
a. Based on Rules
b. Based on Events
c. Based on Responses
3. Experiment framework can be integrated with it.

25. ChatBot: Make it Dynamic
1. Define states.
2. Define Transitions.
a. Based on Rules
b. Based on Events
c. Based on Responses
3. Experiment framework can be integrated with it.
State Machine also sets the philosophy of the chat.

26. ChatBot: Gist
1. Messages should be in order.
2. Messages should rarely drop.
3. Message processing time should be kept in check.
4. Multiple consumers should be used to scale.
5. Message processing failure for one user should not block another user.
6. Chat should be dynamic.

27. Questions?