Lesson 27.1 gave you the doorbell: the outside world knocks, your endpoint answers. But not every building has a doorbell. Some sources never knock — they just leave the information on a shelf, and you have to walk over and look. And some work has nothing to do with outside events at all; it runs because Tuesday arrived.

This lesson gives you the three-way decision. Webhooks are not universally superior. The event — and what the source actually offers — chooses the pattern.

The three patterns, plainly

Webhook: the source pushes now. Service A observes an event and immediately sends your app an HTTP request. Your app reacts within seconds without asking first. Trigger: an outside event. You own the receiving endpoint; the source owns the timing.

Polling: you ask on an interval. Your app repeatedly calls the source's API — "has anything changed since my last check?" — and processes whatever is new. Trigger: your own repeated check. The source never contacts you. This is the pattern when the source has an API but offers no event delivery.

Cron: your own schedule starts known work. A clock fires at a planned time, and your system runs a recurring task — compile the nightly report, clean up expired rows, refresh the dashboard cache. Trigger: time. There may be no external event involved at all; the schedule *is* the reason.

Read the table from left to right as a question: *can the source tell me?* If yes, webhook. If it can only be asked, polling. If nobody needs to tell me anything because the work is mine on a rhythm, cron.

Three examples side by side

Payment completion → webhook. A payment provider observes the checkout event and POSTs to your endpoint within seconds. Freshness matters — the customer is staring at a confirmation screen — and the provider supports event delivery. Your endpoint verifies, records, enqueues fulfillment, and acknowledges fast. (Verification mechanics arrive in 27.3.)

Stock-price snapshot where the provider offers no alerts → scheduled polling. Your chosen market-data provider exposes a quote API but no push events. Your app checks at a reasonable interval — say every fifteen minutes during market hours for a Sonariq-style research panel — compares against the last stored observation, and writes a new row only when the value or timestamp actually changed. The browser never waits; the schedule does the asking.

Nightly report compilation → cron. Nobody rang. Nothing changed on someone else's server that you needed instantly. Your own clock fires at 6 p.m., a job gathers the day's stored observations, builds the report, saves it, and marks it ready. The trigger was time, full stop.

Notice each example names a different owner of timing: the payment provider, your interval checker, your clock. Confusing them causes real bugs — polling a payment API every ten minutes when instant confirmation was available, or waiting for a webhook that a quiet data provider will never send.

Tradeoffs worth weighing

Freshness is the obvious one — webhooks win when seconds matter — but five quieter tradeoffs decide more designs:

• Provider support. Webhooks require the source to offer event delivery with documented payloads, retry behavior, and signing. Many solid data sources simply do not. Polling works anywhere there is a readable API.
• Rate limits. Polling too often can exhaust an API quota or get your key throttled. Poll at the pace the data actually changes — daily filings do not need a one-minute interval.
• Complexity. A webhook means operating a public endpoint: verification, duplicate handling, fast acknowledgement, failure logging. Polling means operating a scheduler plus "what changed since last time" logic. Neither is free; pick the complexity you would rather own.
• Missed-event recovery. Webhooks can fail in transit — your server was down, the network dropped. Serious senders retry, but you still need reconciliation: a periodic check that compares your records against the source. Polling mostly recovers by itself on the next check. Cron needs an explicit "what if the run never happened" plan, as Class 26 taught.
• Cost. Frequent polling burns API calls, compute, and sometimes per-request fees. A webhook costs almost nothing while idle. But an idle webhook still costs you the endpoint's security surface — which Lesson 27.3 prices honestly.

The hybrid reality

Real systems mix all three, deliberately:

• Webhook + daily reconcile. Accept payment events instantly by webhook, then run a once-daily cron job that lists recent transactions from the provider API and confirms every event was recorded. The webhook gives freshness; the reconcile gives completeness.
• Polling → queue. Each poll that finds new items enqueues one job per item instead of processing inline. Ten new filings become ten queue messages; workers process them at a controlled pace. The Class 26 queue absorbs the burst your interval discovered.
• Cron → worker. The clock fires; it does not do the work. A scheduled trigger enqueues a job, and a worker performs the long refresh, report, or cleanup. Time starts it, the queue carries it, the worker finishes it.

If you remember one sentence: the trigger starts the story, the queue carries the load, the record proves what happened.

A reusable decision table

Copy this into your project notes and use it per event:

Check your understanding

1. A provider offers both a webhook and an API. When would you still add polling? 2. Why does polling mostly recover from a missed check on its own, while a webhook needs a reconcile plan? 3. What is the difference between polling and cron — is polling not also "on a schedule"?

Exercise: choose three times

Pick three events from your own product (or Sonariq: a filing update, a macro series release, a user report request). For each, write which pattern you choose, one sentence on the trigger, and one sentence on recovery:

# TRIGGER-CHOICES.md

## 1. [event name] → [webhook / polling / cron]
- Trigger:
- Recovery if the signal is missed:

## 2. [event name] → [webhook / polling / cron]
- Trigger:
- Recovery if the signal is missed:

## 3. [event name] → [webhook / polling / cron]
- Trigger:
- Recovery if the signal is missed:

Use at least two different patterns across the three. If all three answers are "webhook," find the event whose source offers no event delivery and re-decide.

Finish line: three chosen patterns, each with a trigger sentence and a failure-recovery sentence a reviewer could test.

Next, Lesson 27.3 faces the part beginners skip: your webhook endpoint is a public URL. Anyone can knock. Before you open the door, you verify the doorbell.