There is a need to assign specific chat instances for both user and case interactions that can scale dynamically based on demand. These instances should be accessible via a structured URL under chat.atticusai.org.
Problem Definition:
Currently, there is no infrastructure in place to dynamically assign and scale chat instances based on user or case interactions. Users should have a personalized chat instance for their account and a separate instance for each case chat, with URLs structured to reflect these sessions. The system should automatically scale these instances based on user activity.
Motivations:
Implementing this functionality will provide seamless, personalized, and scalable chat experiences for users. This will allow users to interact with their personal chat or case-specific chats efficiently while the system manages the infrastructure scaling.
Proposed Solution:
Set up a system where each user has a dedicated chat instance that deploys when they access their user chat.
Each case will also have a separate chat instance that deploys when accessed.
The system should scale these chat instances up or down based on load.
URLs should follow the format chat.atticusai.org/user/ID/threadID or chat.atticusai.org/user/ID/case/ID/threadID.
Ensure instances can be automatically created, assigned, and scaled.
Definition of Done:
User-specific chat instances are created and assigned upon access.
Case-specific chat instances are created and assigned upon access.
URLs are structured as chat.atticusai.org/user/ID/threadID or chat.atticusai.org/user/ID/case/ID/threadID.
Auto-scaling is in place for both user and case chat instances based on load.
Tested for functionality, scalability, and URL correctness across devices and browsers.
More details
Example Scenario (BDD):
Feature: Dynamically assign user and case-specific chat instances with scalability
As a developer,
I want each user to have their own scalable chat instance, and for each case to have its own scalable chat instance,
so that users can interact with their chats without latency issues, and infrastructure scales based on demand.
Scenario 1: Assigning a user-specific chat instance
Given a user logs in to the application,
When they access their chat,
Then the system assigns a dedicated chat instance,
And the chat is accessible via chat.atticusai.org/user/ID/threadID.
Scenario 2: Assigning a case-specific chat instance
Given a user accesses a case chat,
When they navigate to a specific case,
Then the system assigns a dedicated case-specific chat instance,
And the chat is accessible via chat.atticusai.org/user/ID/case/ID/threadID.
Scenario 3: Auto-scaling based on chat instance load
Given multiple users access their chats simultaneously,
When the load on the chat instances increases,
Then the system scales the instances automatically to handle the demand,
And the chats continue to function without degradation in performance.
Scenario 4: Handling instance shutdown on inactivity
Given a chat instance has been idle for a period of time,
When no activity is detected,
Then the system automatically scales down the instance,
And releases resources to optimize costs.
Which components are impacted by your request?
No response
Pictures
No response
Code of Conduct
[X] I agree to follow this project's Code of Conduct
What features would you like to see added?
Discovery:
There is a need to assign specific chat instances for both user and case interactions that can scale dynamically based on demand. These instances should be accessible via a structured URL under chat.atticusai.org. Problem Definition:
Currently, there is no infrastructure in place to dynamically assign and scale chat instances based on user or case interactions. Users should have a personalized chat instance for their account and a separate instance for each case chat, with URLs structured to reflect these sessions. The system should automatically scale these instances based on user activity. Motivations:
Implementing this functionality will provide seamless, personalized, and scalable chat experiences for users. This will allow users to interact with their personal chat or case-specific chats efficiently while the system manages the infrastructure scaling. Proposed Solution:
Definition of Done:
User-specific chat instances are created and assigned upon access. Case-specific chat instances are created and assigned upon access. URLs are structured as chat.atticusai.org/user/ID/threadID or chat.atticusai.org/user/ID/case/ID/threadID. Auto-scaling is in place for both user and case chat instances based on load. Tested for functionality, scalability, and URL correctness across devices and browsers.
More details
Example Scenario (BDD):
Feature: Dynamically assign user and case-specific chat instances with scalability As a developer, I want each user to have their own scalable chat instance, and for each case to have its own scalable chat instance, so that users can interact with their chats without latency issues, and infrastructure scales based on demand. Scenario 1: Assigning a user-specific chat instance
Given a user logs in to the application, When they access their chat, Then the system assigns a dedicated chat instance, And the chat is accessible via chat.atticusai.org/user/ID/threadID. Scenario 2: Assigning a case-specific chat instance
Given a user accesses a case chat, When they navigate to a specific case, Then the system assigns a dedicated case-specific chat instance, And the chat is accessible via chat.atticusai.org/user/ID/case/ID/threadID. Scenario 3: Auto-scaling based on chat instance load
Given multiple users access their chats simultaneously, When the load on the chat instances increases, Then the system scales the instances automatically to handle the demand, And the chats continue to function without degradation in performance. Scenario 4: Handling instance shutdown on inactivity
Given a chat instance has been idle for a period of time, When no activity is detected, Then the system automatically scales down the instance, And releases resources to optimize costs.
Which components are impacted by your request?
No response
Pictures
No response
Code of Conduct