The two queues
When the extension is installed, two queues are provisioned per tenant:| Queue | Direction | Examples of work |
|---|---|---|
{tenant}-klaviyo-inbound | Klaviyo → Omneo | Klaviyo system webhook events, Klaviyo profile updates flowing into Omneo |
{tenant}-klaviyo-outbound | Omneo → Klaviyo | Omneo profile syncs, Omneo reactions sending metrics, data source record pushes |
task_queue_name setting on the tenant and the configured namespace (defaulting to klaviyo).
Why queues matter
- Fast webhook responses: When Klaviyo or Omneo POSTs to the extension, the request is acknowledged within milliseconds. The actual sync work is deferred to the queue, so the calling system is never blocked.
- Automatic retries: If Omneo or Klaviyo is briefly unavailable or rate limited, the queued task retries with exponential backoff until it succeeds or hits the configured retry ceiling.
- Batching and ordering: Events for the same profile can be combined and processed together (for example, multiple Klaviyo system webhook events arriving close together are merged into a single Omneo update).
- Back-pressure: During traffic spikes (large list imports, bulk profile changes) the queues smooth out load so neither Omneo nor Klaviyo is overwhelmed.
How it works at a high level
- A webhook or target hits the extension.
- The extension performs only the minimum validation (auth, tenant lookup) before enqueuing a task on the appropriate queue.
- Cloud Tasks delivers the task back to the extension’s worker endpoint at a controlled rate, with a fresh Google-issued auth token attached.
- The worker runs the actual sync job (profile upsert, metric send, system webhook processing, etc.).
- Failures are retried; permanent failures are logged for review.