Requirements

Imagine we're building a system that dispatches webhooks to various subscribers whenever certain events occur within our core application (e.g., a user signs up, a payment is processed, an order is shipped). Our goal is to design a flexible and robust webhook dispatcher that can handle different types of events, different delivery mechanisms (HTTP, potentially others in the future), and varying subscriber requirements. We aim for a design that is easily extensible, testable, and maintainable as our system evolves. The core challenge is decoupling the event generation from the webhook delivery process. We want to avoid tightly coupling our application logic with the specifics of how webhooks are sent. We need a mechanism to reliably enqueue webhook delivery requests, handle potential delivery failures, and ensure that webhooks are delivered in a reasonable timeframe. # Requirements ## Functional Requirements 1. **Subscription Management:** * Allow subscribers to register their interest in specific event types (e.g., `user.signup`, `payment.processed`, `order.shipped`). * Each subscription should include the subscriber's URL (where the webhook should be sent), the event type they are interested in, and a list of HTTP headers to be included in the webhook request. * Support adding, updating, and deleting subscriptions. 2. **Event Publishing:** * Provide a mechanism for publishing events to the webhook dispatcher. Each event should have a type and a payload (data). 3. **Webhook Delivery:** * For each event published, identify all subscribers interested in that event type. * Construct an HTTP request for each subscriber, including the subscriber's URL, configured headers, and the event payload as the request body (JSON format). * Asynchronously dispatch the HTTP requests to the subscribers. * Implement retry logic for failed webhook deliveries with configurable retry intervals and maximum retry attempts. * Support configurable timeouts for webhook requests. 4. **Delivery Status Tracking:** * Track the status of each webhook delivery attempt (success, failure, retry count, last error). * Provide a mechanism to query the delivery status of a specific event/subscription. 5. **Payload Transformation:** * Allow subscribers to specify a transformer that alters the event payload before delivery. This enables the same event to have different payload formats based on the subscriber's needs. 6. **Security:** * Include a mechanism for verifying the authenticity of webhooks. For example, include a signature in the header that can be validated by the subscriber. 7. **Filtering:** * Allow subscribers to define filters (e.g., using a simple expression language) that specify which events should trigger a webhook, even for a given event type. This adds more fine-grained control than just event type subscription. ## Non-Functional Requirements 1. **Thread Safety:** The webhook dispatcher must be thread-safe to handle concurrent event publishing and webhook delivery requests. Consider how multiple threads publishing events will interact with the subscription store and delivery queue. 2. **Extensibility:** The design should be easily extensible to support new event types, delivery mechanisms (e.g., different protocols beyond HTTP), and payload transformation strategies without modifying the core dispatcher logic. Using well-defined interfaces and abstract classes is key. 3. **Modularity:** The system should be composed of loosely coupled modules, each responsible for a specific aspect of the webhook dispatching process (e.g., subscription management, event publishing, webhook delivery). This promotes code reusability and maintainability. 4. **Testability:** The design should facilitate unit and integration testing of individual components and the overall system. Consider dependency injection and mocking frameworks. 5. **Resilience:** The system should be resilient to failures, such as network outages or subscriber endpoint unavailability. Retry mechanisms and circuit breakers should be considered. 6. **Observability:** The system should provide metrics and logging to monitor its performance and identify potential issues. Consider exposing metrics like number of events processed, delivery success/failure rates, and latency. 7. **Configuration:** The system should be configurable through external configuration files or environment variables. This allows for easy adjustment of parameters such as retry intervals, timeouts, and thread pool sizes without code changes. 8. **Idempotency:** Consider the possibility of duplicate webhook deliveries due to retries. The system should either guarantee at-least-once delivery with idempotency handled by the subscribers or provide a mechanism for subscribers to detect and handle duplicate deliveries. ## Core Entities 1. **`Event`:** Represents an event that triggers webhook dispatches. It contains the event type and the event payload. 2. **`Subscription`:** Represents a subscriber's interest in a specific event type. It contains the subscriber's URL, the event type, HTTP headers, and optionally a payload transformer and filter. 3. **`WebhookDispatcher`:** The main component responsible for receiving events, matching subscriptions, and dispatching webhooks. 4. **`WebhookDeliveryService`:** Responsible for the actual delivery of webhooks (HTTP requests). This might include retry logic and error handling. Consider an interface to allow different delivery strategies. 5. **`SubscriptionStore`:** Manages the storage and retrieval of subscriptions. Consider thread-safe implementations. 6. **`PayloadTransformer`:** An interface for transforming the event payload before delivery. Different implementations can be plugged in to support different transformation strategies. 7. **`Filter`:** An interface for filtering events based on subscriber-defined criteria. 8. **`DeliveryAttempt`:** Represents a single attempt to deliver a webhook. Stores information about the attempt, such as timestamp, status, and any errors encountered.

Design Webhook Dispatcher.

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content