---
Title: Send guarantees
URL Source: https://company-skill.com/p/rocketmq/rocketmq-send-guarantees
Language: en
Description: You need to send messages in RocketMQ with specific delivery guarantees—such as strict ordering within a partition, two-phase commit for distributed transactions, or scheduled/delayed delivery—while…
---

# Send guarantees

Part of **Apache RocketMQ**. Route queries via `POST https://company-skill.com/api/route`.

## What You Want to Do

You need to send messages in RocketMQ with specific delivery guarantees—such as strict ordering within a partition, two-phase commit for distributed transactions, or scheduled/delayed delivery—while ensuring correctness, consistency, or testability.

**Typical User Questions**:
- How to send ordered messages in RocketMQ?
- Can I send transactional messages with RocketMQ?

## Decision Tree

Pick the best path for your situation:

- **If** you are testing or debugging without writing code and only need basic message validation → Use Send Message via Console (go to *rocketmq/rocketmq-message*)
- **If** your business logic requires strict message order within a partition (e.g., all messages for user ID "123" must be processed in send order) and you use a `shardingKey` → Use Send Ordered Message via Java SDK (go to *rocketmq/rocketmq-message*)
- **If** you are implementing a distributed transaction that requires atomicity between a local database update and message sending using two-phase commit → Use Send Transactional Message via Java SDK (go to *rocketmq/rocketmq-message*)
- **Otherwise (default)** → Use Send Message via Java SDK for standard, delayed (`delayLevel` 0–18), or one-way messaging in production code with `synchronous sending`, `asynchronous sending`, or fire-and-forget patterns.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| Send Message via Java SDK | When building applications that need to programmatically send standard, scheduled, or delayed messages. | medium | Yes | Yes | Supports `delayLevel` 0–18; max message body 4MB | `rocketmq/api/rocketmq-message` |
| Send Transactional Message via Java SDK | When implementing distributed transactions requiring two-phase commit for data consistency. | high | Yes | Yes | Limited to 100 QPS per instance; requires `LocalTransactionExecuter` and `TransactionCheckListener` | `rocketmq/api/rocketmq-message` |
| Send Ordered Message via Java SDK | When strict message order within a partition (by sharding key) is required for correctness. | medium | Yes | Yes | Order guaranteed only within same `shardingKey` and single consumer thread | `rocketmq/api/rocketmq-message` |
| Send Message via Console | When testing or debugging message production without writing code. | low | No | No | Max message body 64KB; cannot send transactional or ordered messages | `rocketmq/api/rocketmq-message` |

## Path Details

### Path 1: Send Message via Java SDK

**Best For**: When building applications that need to programmatically send standard, scheduled, or delayed messages.

**Brief Description**: Uses the `DefaultMQProducer` from the `rocketmq-client-java>=4.9.0` library to send `Message` objects to a `topic` with optional `tag` and `delayLevel`. Supports `synchronous sending`, `asynchronous sending`, and one-way modes, returning a `SendResult` for confirmation.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request. Standard messages: 10,000 free sends per month.
- Runtimes: Java 8+
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Need to send standard messages programmatically with delivery confirmation
- Require scheduled or delayed message delivery with `delayLevel` parameter
- Building applications that need `synchronous sending`, `asynchronous sending`, or one-way sending patterns
- Implementing production systems requiring code-based message sending with error handling

**When NOT to Use**:
- Need to implement distributed transactions requiring two-phase commit (use transactional message path)
- Require strict message ordering within a partition (use ordered message path)
- Just testing or debugging without writing code (use console path)

**Known Limitations**:
- Message body maximum size is 4MB
- Topic name maximum length is 255 characters with only alphanumeric, hyphen, and underscore allowed
- Rate limited to 1000 QPS per topic

### Path 2: Send Transactional Message via Java SDK

**Best For**: When implementing distributed transactions requiring two-phase commit for data consistency.

**Brief Description**: Uses `TransactionProducer` and the `sendMessageInTransaction()` method to send a "half message" that remains invisible until the local transaction (executed via `LocalTransactionExecuter`) commits or rolls back. A `TransactionCheckListener` handles status uncertainty, returning `TransactionStatus` such as `CommitTransaction` or `RollbackTransaction`.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request. Transactional messages: 1,000 free calls per month.
- Runtimes: Java 8+
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Implementing distributed transactions requiring two-phase commit for data consistency
- Need atomicity between local database operations and message sending
- Building systems that require transaction status uncertainty checks via `TransactionCheckListener`
- Handling scenarios where local transaction failures must trigger message rollback

**When NOT to Use**:
- Only need to send standard messages without transaction guarantees (use standard message path)
- Require strict message ordering within a partition (use ordered message path)
- Just testing or debugging without writing code (use console path)

**Known Limitations**:
- Transaction producers limited to 100 QPS per instance
- Requires implementing both `LocalTransactionExecuter` and `TransactionCheckListener`
- More complex implementation compared to standard message sending
- Message body maximum size is 4MB

### Path 3: Send Ordered Message via Java SDK

**Best For**: When strict message order within a partition (by sharding key) is required for correctness.

**Brief Description**: Uses `DefaultMQProducer` (or `OrderProducer`) with `producer.send(message, shardingKey)` to ensure all messages sharing the same `shardingKey` (a `partition key`) are routed to the same `message queue`, enabling `sequence guarantee` during consumption. This enables true `ordered message` processing.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request. Ordered messages: 100,000 free requests per month.
- Runtimes: Java 8+
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Strict message order within a partition (by `shardingKey`) is required for correctness
- Need to ensure related messages (e.g., user transactions) are processed in send order
- Building systems where message sequence affects business logic correctness
- Implementing scenarios like order processing where sequence matters

**When NOT to Use**:
- Need distributed transactions with two-phase commit (use transactional message path)
- Only need to send standard messages without ordering guarantees (use standard message path)
- Just testing or debugging without writing code (use console path)

**Known Limitations**:
- Ordered messages guaranteed only within a single consumer thread for messages sharing the same `shardingKey`
- Key maximum length is 512 characters
- Consumers must also use ordered consumption to maintain sequence
- Message body maximum size is 4MB

### Path 4: Send Message via Console

**Best For**: When testing or debugging message production without writing code.

**Brief Description**: A web-based interface accessible via " > > > " that allows `manual sending` of messages by specifying `topic`, `messageBody`, `tag`, and `delayLevel`. No code or `rocketmq-client-java>=4.9.0` dependency needed.

**Key technical facts**:
- Billing: Per-request billing model where each message send operation is counted as one request.
- Max concurrency: 10 concurrent connections per client

**When to Use**:
- Testing or debugging message production without writing code
- Quick validation of topic configuration and message format
- Manual message sending for development and troubleshooting
- Verifying basic message delivery without implementing producer code

**When NOT to Use**:
- Building production applications requiring programmatic message sending
- Need transactional message guarantees with two-phase commit
- Require strict message ordering within a partition
- Implementing automated or scheduled message sending workflows

**Known Limitations**:
- Not automation-friendly (manual UI interaction required)
- Message body maximum length is 64KB (65536 bytes)
- Cannot implement transactional or ordered message guarantees through console
- Delay level range is 0–18 (same as SDK)

## FAQ

Q: Which path should I start with?
A: Start with **Send Message via Java SDK** if you're building production code that doesn’t require ordering or transactions. It supports `delayLevel`, `tag`, and all core sending patterns with the highest free tier (10,000 messages/month).

Q: What if I need strict message ordering but used the standard SDK without a `shardingKey`?
A: Messages with the same logical key (e.g., user ID) may land on different queues, breaking the `sequence guarantee`. You’ll observe out-of-order consumption even if sent in order—use **Send Ordered Message via Java SDK** with `producer.send(message, shardingKey)` instead.

Q: What if I’m implementing a payment system that updates a database and sends a message, but chose the standard SDK instead of transactional?
A: If the database update succeeds but the message send fails (or vice versa), you’ll have inconsistent state. Only **Send Transactional Message via Java SDK** ensures atomicity via `half message` and `TransactionStatus` callbacks.

Q: Can I send a 100KB message body using the Console?
A: No—the Console limits `messageBody` to 64KB. For larger payloads up to 4MB, use any Java SDK path (`DefaultMQProducer`, `TransactionProducer`, or `OrderProducer`).

Q: Does the Console support `delayLevel`?
A: Yes—it supports `delayLevel` 0–18, just like the Java SDK. But it cannot send `ordered message` or `transactional message` types.

Q: Are all paths compatible with Java 11?
A: Yes—all Java SDK paths require `rocketmq-client-java>=4.9.0`, which supports Java 8+. The Console has no runtime dependency.

Q: What happens if I exceed 100 QPS on a transactional producer?
A: You’ll hit rate limits since transactional producers are capped at 100 QPS per instance. Standard and ordered producers allow up to 1000 QPS.

## Related queries

send message with guarantee, send guaranteed message, how to send ordered message, can I send transactional message, RocketMQ delayed message, send message with delivery guarantee, send sequence message, implement distributed transaction RocketMQ, send message by sharding key, RocketMQ transactional

---
Part of [Apache RocketMQ](https://company-skill.com/p/rocketmq.md) · https://company-skill.com/llms.txt