## Problem: "Event fire" / event dispatcher with multithreading Design an in-memory event system that supports registering listeners and firing events. ### Core requirements Implement an `EventDispatcher` (or `EventBus`) supporting: - `subscribe(eventType, listener)` - `unsubscribe(eventType, listener)` - `fire(eventType, eventPayload)` — invokes all listeners currently subscribed to `eventType` Where `listener` is a callback/function. ### Follow-ups (multithreading) Assume `subscribe`, `unsubscribe`, and `fire` can be called concurrently from multiple threads. Answer/discuss: 1. What thread-safety guarantees will you provide? (e.g., “listeners registered before fire starts must be called exactly once”, handling concurrent unsubscribe, etc.) 2. How will you avoid race conditions and deadlocks? 3. How will you handle performance trade-offs under high read (fire) vs high write (subscribe/unsubscribe) workloads? 4. Will `fire` be synchronous (caller thread) or asynchronous (thread pool / queue)? How does that change your design? You may state reasonable assumptions (e.g., per-event-type ordering is or isn’t required; at-least-once vs exactly-once delivery within a single process).