Design Webhooks and Metric Aggregation

The interview report described two system design rounds: a webhook delivery platform and a vehicle metrics aggregation system.

Constraints & Assumptions

• For webhooks, assume multi-tenant external delivery over HTTPS with at-least-once semantics.
• For telemetry, assume many connected vehicles send measurements every few seconds.
• Discuss APIs, storage, queueing, retries, security, observability, scaling, and fault tolerance.
• Make delivery and aggregation tradeoffs explicit.

Clarifying Questions to Ask

• For webhooks, what event volume, tenant count, latency target, payload size, and ordering requirements exist?
• Can customers replay missed webhook events?
• For telemetry, how many vehicles and events per second are expected?
• What retention and query latency targets are required?
• Are alerts real-time, batch, or both?

Part 1 - Design Webhook Delivery

How would you design a multi-tenant webhook platform?

What This Part Should Cover

• APIs for endpoints, subscriptions, secrets, logs, and replay.
• Event bus, subscription lookup, fanout, delivery queue, workers, retry queue, dead-letter queue, and observability.
• At-least-once delivery, idempotency, signing, tenant isolation, and failing endpoint protection.

Part 2 - Design Vehicle Metrics Aggregation

How would you design a telemetry aggregation platform for connected vehicles?

What This Part Should Cover

• Ingestion gateway, stream platform, stream processing, raw storage, hot aggregate store, dashboard serving, alerting, and batch reprocessing.
• Handling duplicates, late events, out-of-order events, missing data, retention, and downsampling.