Delay Policy

Overview

A delay policy defers when a queued message becomes visible to consumers — you send it now, but nothing can receive it until a countdown you set expires. That's the mechanism behind retry-after-backoff, rate-limited notifications, "remind me in an hour" workflows, and staggering a burst of work so it doesn't hit downstream consumers all at once, all without standing up a separate scheduler.

It works entirely at send time: .delay_seconds(15) on QueueMessageBuilder attaches a delay to the message before it's passed to send_queue_message. The broker starts the countdown the moment it accepts the message and simply excludes it from delivery until the timer elapses — after that it behaves like any other queued message, available to whichever consumer polls next.

Gotchas: the delay is a floor, not a guarantee — the message becomes eligible when the timer expires, but actual delivery still waits for a consumer to poll, so don't rely on it for precise scheduling. It's one-shot: there's no recurrence or cron-like behavior, so long or repeating delays need application logic on top. And it's independent of redelivery — a delayed message that's later nacked or times out after delivery follows normal visibility-timeout/retry rules, not the original send-time delay.

Prerequisites

• KubeMQ server running on localhost:50000
• Rust SDK installed (cargo add kubemq)

Code

use kubemq::prelude::*;
use kubemq::QueueMessageBuilder;

#[tokio::main]
async fn main() -> kubemq::Result<()> {
    let client = KubemqClient::builder()
        .host("localhost")
        .port(50000)
        .build()
        .await?;

    let msg = QueueMessageBuilder::new()
        .channel("rust-queues.delay-policy")
        .body(b"delayed-policy-msg".to_vec())
        .delay_seconds(15)
        .build();

    let result = client.send_queue_message(msg).await?;
    println!("Sent with delay policy: id={}, delayed_to={}", result.message_id, result.delayed_to);

    client.close().await?;
    Ok(())
}

How It Works

• delay_seconds is set via the message builder as part of the queue policy.
• The server holds the message until the delay period expires.
• Review timeouts, channel names, and client IDs before running against shared environments.
• Run the program while the server from the prerequisites is available.

Related

• Delayed Messages — task-oriented walkthrough for sending delayed messages
• Queues overview
• Rust SDK Reference