This is a clone of the intercom or tawk.
It doesn’t have ai integration; rather, a live agent will communicate with a user.
- A tenant creates an account on the site.
- The tenant creates a chatbot and is given an API key.
- The tenant embeds the chatbot on their website using the API key and tenant ID.
- When a user initiates a chat, the chatbot asks for their email address and creates a new chatroom for the user.
- The chatbot sends a message to the chatroom notifying the user that a live agent will join the chat shortly.
- The chatroom service sends a message to a message queue indicating a new chatroom has been created.
- A live agent joins the chatroom and begins communicating with the user.
- As messages are sent between the user and the agent, they are stored in the message table in the database and displayed in the chatroom UI.
- The analytics service periodically pulls data from the database and generates usage reports.
- Nestjs
- MongoDB
- Kafka with Redpanda
- Tinybird
- Redis
Requests from the chatbot will be handled by nginx.
Nginx handles:
- Load balancing
- SSL termination
Nginx will forward the request to the appropriate microservice.
Nginx will handle load balancing between replicas of the microservices based on some appropriate algorithm.
- Chat servers → Based on server
- The rest will be round-robin based.
- Analytics service
- Tenant services
- Chat Service
- Email Service
This service will allow a new tenant to create an account and profile.
This service will allow tenants to create, update and delete users/ agents.
This service will allow tenants to create, update and delete chatbots.
This service will handle auth and roles.
This service will allow users to create a chatroom using their email and IP address for auth.
Browser info will be stored as metadata.
Chat service will authenticate chatrooms with a jwt added security.
This service will handle analytics for the whole system.
Analytics data points:
- Application live status
- Tenant chatbots status
\
This service will be used to send emails as the primary notifications
Profile Data Fields
- Name
User Data Fields
- password
- roles
- Name
- refresh token
- assigning
- PasswordChangeToken
- IP addresses
- \
Roles Data Fields
- name
- Id
Chatbot data fields
- Id
- APIKEY
- tenantId
A tenant will create an account where they’ll set up their name, admin pass, and admin email.
The admin tenant will have all roles and can create new roles.
The admin can add users.
The admin can assign/ deny permissions to users.
The admin can create, delete, and update chatbots.
A user/ agent can connect to a chatroom.
The user/ agent can mark a chatroom as stale/ blocked.
User will add their email and name to the chatbot.
The chatbot will create a chatroom, send a welcome email to the user, add the chatroom to a queue for a live agent to join.
The chatroom will add the message to a queue after emitting the message to the recipient.
The chatroom will have Redis caching.
The chatroom will have a 10 min standby mode where a user can continue asking questions and reconnect in case of network failure.
The chatroom will handle auth via sessions.
Chatroom data fields
- name
- agentName
- agentEmail
- agentId
- createdAt
- updatedAt
- message: [{ message, sentAt, read, sender }]
\
The service will provide handle analytics for the system
- Infra analytics:
Will return the system live status.
A discovery service can check on the availability of the whole infra.
- Tenant Specific analytics with integrations with tinybird
This service will handle all email notifications.
The service will consume various notifications from a queue.
Can be improved to razor pay design.
Queues
Kafka is used for queueing as well as streaming for realtime analytics and communications.
\