Backend Study Lab · Games
← All games

Webhook Signature Forensics

Investigate webhook requests and choose safe handling for signatures, replay windows, retries, idempotency, and durable acknowledgement.

Concept
Webhook verification, replay protection, idempotency, and retry-safe processing
Difficulty
Intermediate
Play time
6-9 minutes
Path
Foundations

Interactive scenario

Playable game area: Make the next backend decision

Use the controls below. Feedback appears immediately and final scores stay in this browser.

Concept notes

Why this decision matters

Webhook Signature Forensics is focused practice for Webhook verification, replay protection, idempotency, and retry-safe processing. It explains why each answer is safe, risky, or production-ready.

Webhook endpoints are tiny doors into important backend state. This game treats each delivery like a forensic case: prove the evidence is authentic, fresh, unique enough, and safely accepted before it changes anything valuable.

Learning objectives

  • Verify webhook authenticity using raw request bodies and signatures.
  • Recognize replay attacks, duplicate deliveries, and unsafe side effect ordering.
  • Design webhook handlers that acknowledge only after durable acceptance.

How to play

  1. Inspect the webhook evidence: body handling, signature, timestamp, event id, and side effects.
  2. Choose the handler behavior that keeps production state trustworthy.
  3. Read each explanation to separate authenticity, freshness, and retry safety.

Scoring

  • Correct investigations add points and streak bonuses.
  • Risky decisions reveal how webhook handlers fail in production.
  • Final score is saved locally and can be submitted to the leaderboard.

Backend concept notes

Webhook delivery is at-least-once in many systems, so valid events can arrive more than once. The handler must verify the sender and make side effects idempotent.

A safe webhook path verifies the raw signed payload, enforces timestamp tolerance, stores dedupe state, persists accepted work durably, and returns 2xx only after the event is safe to process internally.

Common mistakes

  • Verifying a re-serialized JSON body instead of the raw body bytes.
  • Treating a valid signature as proof that the event is fresh or unique.
  • Sending emails or charging accounts before durable dedupe state exists.
  • Returning 500 for work that has already been durably accepted.

Review misses from this game

Related Backend Study Lab tools

Use tools from the main site when you want to inspect real inputs.

Keep practicing nearby backend concepts while the mental model is fresh.

APIs Beginner

API Route Builder

Design REST-style methods and routes for product requirements such as creating users, updating email, searching products, and nested comments.

Time
6-9 minutes
Concept
REST API route design
  • Foundations
  • REST
  • API design
  • routes
Play API Route Builder
Reliability Intermediate

Idempotency Key Clinic

Diagnose retry scenarios and choose safe idempotency behavior for payments, emails, imports, orders, PUT updates, and scarce inventory.

Time
6-9 minutes
Concept
Idempotency, retries, duplicate prevention, and consistency
  • Production Reliability
  • Async Workflows
  • Idempotency
  • Reliability
  • Consistency
Play Idempotency Key Clinic
Queues Intermediate

Message Queue Simulator

Tune workers, retries, and dead-letter behavior while jobs move through an async queue with failures and poison messages.

Time
7-11 minutes
Concept
Async jobs, retries, visibility timeout, and dead-letter queues
  • Production Reliability
  • Async Workflows
  • queues
  • retries
  • dead-letter queue
Play Message Queue Simulator

FAQ

Short answers for how this game fits backend interview and study practice.

Why do webhooks need idempotency if they are signed?

A signature proves who sent the event. It does not prove this is the first delivery. Providers retry signed events after timeouts and network failures.

Should webhook handlers do all business work synchronously?

Usually no. A common pattern is verify, persist, enqueue internal work, then acknowledge with 2xx so provider retries do not amplify downstream delays.

Leaderboard

Top 10 scores for the current ruleset. No account required.

Loading leaderboard...

    Finish the game to load your latest local score.