QUIC Client

Low-overhead QUIC submission for workloads that cannot hold a persistent connection open.

Nozomi provides a native QUIC client for submitting transactions:

github.com/temporalxyz/nozomi-quic-client →

When to Use It

QUIC is not faster than the HTTP endpoints when you keep a warm connection open. Over a persistent, reused TCP connection, Batch Send over a direct http:// endpoint is the lowest-latency path (see Regions & Endpoints → Choosing a submission method).

QUIC is useful for a specific case: workloads that cannot hold a single connection open and have to re-establish a connection frequently. QUIC's connection setup (including session resumption) is cheaper than repeatedly completing a fresh TCP + TLS handshake, so you pay less latency per reconnect.

Use QUIC when:

• You cannot maintain one long-lived, warm connection to a region.

• Your process is short-lived, serverless, or otherwise reconnects often.

• Network conditions force frequent reconnection.

If you can keep a connection open, prefer Batch Send or API v2 over a direct http:// endpoint instead, and use TCP Keep-Alive to keep it warm.

Notes

• The transport you choose does not change your priority in Nozomi's queue: priority is driven by your tip, not by QUIC vs HTTP.

• Like API v2 and Batch Send, QUIC submission does not return a transaction signature. Compute and track the signature client-side before submitting.