Webhook Delivery Service: Reliable Event Delivery Under Constraints

Description

You're a software engineer on a growing B2B SaaS platform. Three of your largest clients have integrations that depend on knowing when things happen in your system — a record is updated, a status changes, a transaction is processed. Right now they're polling your API every 30 seconds. It's slow, noisy, and burning API capacity. They've all asked for webhooks.

Engineering has been asked to build a webhook delivery layer as a proof-of-concept: a service that accepts events from the platform and delivers them to client-registered endpoints, with retry logic for failed deliveries. Your job is to build the core delivery mechanics and show you understand what it will take to make this reliable in production. You have 30 minutes for the build phase.

Requirements:

• Event intake — accept event payloads (event type, payload body, client ID) and enqueue them for delivery without blocking the caller
• Endpoint delivery — deliver payloads to each client's registered webhook URL via HTTP POST; treat any 2xx response as success
• Retry logic — retry failed deliveries with backoff across at least 3 attempts (configurable); retry timing is up to you — document your choice
• Delivery status — track and expose delivery status per event: pending, delivered, failed, exhausted

Constraints to Consider

• In-memory only — no database, no message queue (Kafka, RabbitMQ, SQS, etc.), no Redis. Address what breaks under this constraint and what changes when infrastructure becomes available.
• Any language or framework — language choice is not scored; engineering judgment is.
• Must be implemented as a service or module — event handlers call your service; they do not contain their own delivery logic. The delivery concern must be decoupled from the event trigger.
• Async-first communication — your README is how the team understands your work. Write it for someone reading at 11pm who can't ask follow-up questions.
• Demonstrate known failure modes — what happens when a client endpoint is slow, down, or returning 5xx intermittently? What happens on process restart? Don't pretend these don't exist.

AI Usage Guidance

We expect you to use AI tools. We evaluate how you use them — not whether you use them.

Evidence of iteration, redirection, and critical evaluation scores higher than a polished output with no process documentation.

The single highest-signal artifact in this challenge is your video answer to the mandatory question below. A candidate who can tell a specific, honest story about pushing back on the AI reveals more about their engineering judgment than 100 lines of clean code.

Mandatory AI question for your video: Pick a moment in this challenge where the AI gave you something you didn't fully trust or agree with. Talk us through it like you're decompressing with a teammate at the end of the day — what were you going for, what did the AI give you instead, and what did you actually do? Be specific about the moment. A vague answer about AI limitations tells us nothing; a real story tells us everything.

Speak naturally and directly. We are not evaluating your presentation polish — we are evaluating how you think.

We suggest you do not read from a script or transcript generated by AI.

Submission: Upload each deliverable as a separate file directly on the Provn platform: your code submission, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).