Queen commits a few things together that usually live in different systems: the ack of a message, a write to its KV store, pushes to other queues, and timers. These guides put that to work on problems that normally need an outbox table, a lock service, a scheduler or a separate stream processor beside the broker. Each one starts from code that runs and ends with the edges it has.
If you read one, read the state machine. The other patterns are variations of its single transaction.
Patterns
- One state machine per entity: an order that is created, paid and shipped, or cancelled by its own timer, run by stateless workers without locks.
- Charge a card once: a redelivered order made harmless by a marker that commits with the ack.
- Deliver webhooks: in order per endpoint, retried by the broker, and dead-lettered with the error when an endpoint never answers.
Features
- Streams: windows and aggregates in your own process, with the state kept in Queen and one commit per cycle.
- Ephemeral queues: in-memory queues for request/reply, presence and signals, served by every node of a cluster and handed over when a node stops.
Integrations
- Kafka clients: point an unmodified Kafka client at the broker. A topic is a queue, so a native consumer reads what a Kafka producer wrote, and the other way round.
- Kafka Streams, Connect and Flink: what each framework asks of the broker, what has run against it, and where each one stops.
- Postgres source and sink: stream PostgreSQL tables into queues and queues into tables from inside the broker, with exactly-once effects in both directions.
- S3 sink: mirror queues into an S3-compatible bucket as JSONL or Parquet from inside the broker, exactly once, in a layout DuckDB and Spark read directly.
- Laravel: Queen as a Laravel queue connection, with worker supervisors, their dashboard, scaling on Kubernetes and monitoring.