backend-message-queue

Backend Message Queue

Purpose

Design consistent, production-grade message-driven systems. Every message flow must follow the same conventions for broker selection, topic/queue topology, message schema, delivery guarantees, consumer idempotency, retry, and dead-letter handling.

Agent Protocol

Trigger

Exact user phrases: "message queue", "Kafka", "RabbitMQ", "SQS", "pub-sub", "event bus", "consumer group", "topic", "queue", "at-least-once", "exactly-once", "idempotent consumer", "event sourcing", "dead letter queue", "DLQ", "message broker", "producer", "consumer", "event-driven", "async processing", "design a message flow".

Input Context

Before activating, verify:

• The business event or asynchronous task is known.
• The delivery guarantee requirement (at-most-once / at-least-once / exactly-once) is known. If not, ask: "What delivery guarantee do you need?"
• The throughput requirement is known.
• The broker preference (Kafka / RabbitMQ / SQS) is known. If not, ask: "Which broker? Kafka (high throughput, replay), RabbitMQ (routing, flexibility), or SQS (managed, simple)?"

Output Artifact

No file output unless the user requests it. Produces messaging topology specs as text.

Response Format

For each topic/queue:

Broker: {Kafka | RabbitMQ | SQS}
Name: {topic or queue name}
Type: {topic | queue | exchange + queue}
Partitions: {number} / Shards: {number}
Retention: {TTL or size limit}
Consumers: {consumer group or worker pool}
Dead-letter: {DLQ name}

For each message type:

Schema: {event_name} v{version}
Key: {partition key field}
Payload: {field list}
Guarantee: {at-most-once | at-least-once | exactly-once}
Idempotency key: {field name}

No preamble. No postamble. No explanations. No filler/hedging/transitions. Compress output — why use many token when few do trick.

Completion Criteria

• Broker is selected with justification.
• Every topic/queue has: name, type, partitions, retention, consumers, DLQ.
• Every message has: schema with version, key, payload, delivery guarantee, idempotency key.
• Consumer failure handling (retry policy, DLQ routing) is defined.
• Ordering requirements are documented (key-based partitioning).
• Schema evolution strategy is defined.