Sub‑20ms Latency

Hyrex is engineered for low enqueue→start latency. With co‑located workers, tuned queues, and zero heavy coordination on the hot path, typical p50 dequeue latency can stay under 20ms.

The design avoids central bottlenecks: workers keep warm connections, use lightweight claims, and batch acks. You get fast wake‑ups without aggressive polling or noisy spin loops.

How we keep latency low

• Co‑location: Place workers near your database or use a low‑latency private link to minimize RTT.
• Warm connections: Pooled connections with prepared statements—no per‑task handshake.
• Lightweight claims: Optimistic task claiming with minimal locking and batched status updates.
• Signal‑driven wakeups: Event signals nudge workers to pick up work quickly without hot polling.
• Queue partitioning: Separate IO/CPU queues and per‑queue concurrency to avoid head‑of‑line blocking.
• Prefetch window: Small, configurable prefetch keeps executors fed while avoiding bursty spikes.

Recommended setup

• Run workers close to data: Same region/AZ as your Postgres to keep network latency negligible.
• Use dedicated queues: Route fast paths to their own queue, reserve others for slow or bursty jobs.
• Right‑size concurrency: Match executor concurrency to CPU and downstream limits; avoid oversubscription.
• Batch writes: Prefer fewer, larger updates for acks/metrics over many tiny ones.
• Measure p50/p99: Track dequeue latency and throughput in Studio; alert on regressions.

Task and queue tips

• Pick the right queue: Configure tasks with withConfig({ queue }) to isolate hot paths.
• Bounded work: Keep individual tasks focused and short; split long work into steps or a workflow.
• Retry smartly: Use capped retries with jitter to protect latency under partial failures.

Verify in Studio

Use the open‑source Studio to inspect dequeue latency and throughput by queue. Watch p50/p95/p99 while tuning concurrency and queue placement.