Design a customer support agent dispatcher that handles mid-request breaks

Design and implement the core of a dispatcher for a customer support team. Customers contact support and wait for help. Human support agents sign in, serve one customer request after another, and sometimes leave. The dispatcher decides which agent serves which waiting customer, and when. Model the main entities as classes, implement the operations that change state, and then handle the follow-up: an agent is interrupted in the middle of serving a customer to go on break. Assume a single process holds all state in memory and receives events one at a time, each with a timestamp, so behavior is deterministic and testable. Where a business policy is not given below, ask about it instead of assuming it. ### Clarifying Questions - Does an agent serve one customer at a time, or several at once up to a cap? - Which waiting customer is served first: strict arrival order, or do priorities or required skills change the order? - When several agents are free, which one receives the next customer: the agent idle the longest, the one who has handled the fewest requests, or any of them? - Can a waiting customer give up and leave the queue? - Does the dispatcher need to record wait and handling times for reporting? ### Part 1 — Core dispatcher Define the entities (for example an agent, a customer request and the dispatcher itself), their fields, and the states each can be in. Implement operations such as: - an agent becomes available (signs in or returns); - a customer request arrives; - an agent finishes the request they are serving; - an agent signs out. Every operation should make any assignment that has just become possible. State the time complexity of each operation. ```hint States before structures List the states an agent and a request can be in, and the events that move them between states, before you pick any queue. ``` #### What This Part Should Cover - Agent and request state machines, with illegal or repeated events rejected or ignored deliberately - Structures for waiting customers and free agents that make each assignment decision cheap - Assignment triggered by every event that adds demand or frees capacity - Complexity of each operation in terms of agents and waiting customers ### Part 2 — An agent is interrupted mid-request to take a break While serving a customer, an agent is interrupted and goes on break. What happens to the agent, and what happens to the customer they were serving? Extend the design and the code to support going on break and returning from a break. ```hint The customer left behind Decide where the interrupted customer belongs relative to customers who arrived after them, and what must travel with them so the next agent does not start over. ``` #### Clarifying Questions for this Part - Is the break immediate, or may the agent finish the current customer first? - Should the interrupted customer go to the next free agent, or wait for the same agent to return? - Can an agent go on break while idle, and what happens if the break event arrives twice? #### What This Part Should Cover - A break state with transitions into and out of it, for both busy and idle agents - A re-queue or hand-off policy that keeps the interrupted customer's place and context - Late or stale events, such as a "finished" event for a customer who was already handed to someone else - Customers who are interrupted repeatedly ### What a Strong Answer Covers - Explicit state machines for agents and requests that the code follows - A separation between the entities and the assignment policy, so the policy can change without rewriting the classes - Correct state after every event, including duplicates and events that arrive later than expected - Fairness: a customer's place in line does not depend on events outside their control - Per-event cost analysis and a plan for testing with injected timestamps ### Follow-up Questions - Some requests need a skill (for example, billing) that only some agents have. How do the queues change? - Agents may now hold up to three conversations at once. What replaces the free-agent structure? - One process can no longer hold every agent and queue. How would you split the dispatcher across servers without assigning one customer twice? - What metrics would show a supervisor that breaks are hurting customer wait times?