Skip to lesson
Exit
GTM Systems Design1 / 3

1 min lesson

Rate limits, backoff and queueing

Rebuild the main list in "Rate limits, backoff and queueing", then say what each item changes.

Step 1 of 3

Rate limits, backoff and queueing

Third-party APIs throttle you and a burst of leads will hit those limits. Smooth the load instead of hammering through it.

  • Queue work and drain it at each provider's allowed rate rather than firing the whole batch at once.
  • On a 429, back off exponentially with jitter so a thundering herd of retries doesn't sync up and re-spike.
  • Respect Retry-After headers when a provider tells you exactly when to come back.
  • Set a sane max-retry ceiling, then dead-letter - infinite retries on a permanently failing call just burn budget.
Learn more

Full explanation

Monitoring, alerting, runbooks

Monitoring, alerting, runbooks

A silent GTM pipeline is a broken one nobody noticed yet. You want to catch a stall before a rep complains that the leads dried up.

Watch
Throughput
Healthy
Leads/hour in a normal band
Alert when
Volume drops to ~0 unexpectedly
Watch
Match rate
Healthy
Enrichment hit-rate steady
Alert when
Coverage falls sharply (provider down?)
Watch
SLA breaches
Healthy
Near zero
Alert when
Breaches spike - routing or capacity broke
Watch
Error / DLQ rate
Healthy
Low and flat
Alert when
Dead-letter queue grows quickly

Pair each alert with a runbook: what it means, first thing to check, how to safely re-run.

Graceful degradation

When a provider is down, the pipeline should keep moving on what it has rather than freeze. Partial enrichment that scores and routes beats a stalled queue that delivers nothing.

Degrade, don't dam

If the technographic provider is down, score on firmographics and usage now, mark the missing fields open and backfill when the provider recovers. A lead routed in 15 minutes on 80% of its profile is worth more than a perfect profile that arrives after the buyer went cold.

Learn more

Full explanation

Versioning and safe rollout

Versioning and safe rollout

Changing live scoring or routing logic is changing a system reps depend on right now. Ship it like a code deploy, because it is one.

Version it

Tag each scoring/routing change with a version on every decision log, so you can compare cohorts before and after.

Shadow first

Run the new logic alongside the old without acting on it; compare what would have changed before you flip it.

Roll back fast

Keep the previous version one toggle away. A bad routing change should revert in minutes, not a rebuild.

Say it like this

"I treat the pipeline like a service: every action is idempotent so retries are safe, every external call is queued and backed off against rate limits and every scoring change ships shadowed with a version stamp so I can compare cohorts and roll back in minutes if routing regresses."

QYour orchestrator delivers events at-least-once, so a webhook can fire twice. What's the single most important pattern to keep a duplicate from double-creating a record or double-sending an email and how does it work?