Appearance
What Spooler is not
Spooler is a message queue: messages go in, are delivered at least once, and leave. Use it when your application runs the workers and needs a managed queue for handing out work, retrying what failed, and acknowledging what is done — without operating a broker or a Redis for it. Everything else is a non-goal — not a roadmap gap.
- A stream processor. No replay, no offsets, no consumer groups: an acked message is gone. If you need to reprocess history or run windowed computations, that's Kafka or Redpanda.
- A drop-in for an existing broker. Spooler has its own API: AMQP, STOMP, MQTT, and Kafka-protocol clients do not connect, and there is no exchange/binding model to port. If keeping your current client libraries or AMQP routing is the requirement, that's RabbitMQ.
- A pub/sub bus. No topics, no fan-out, no routing rules: one queue, one consumer pool, each message delivered to one receiver at a time. If every subscriber needs its own copy, that's NATS or SNS.
- A workflow engine. Spooler does not execute jobs or coordinate your application's steps: your workers receive messages and run the work, and Spooler never calls your code — your code calls Spooler. Delivering webhooks is a fine use; being one is not. If you need durable multi-step orchestration, that's Temporal.
- A scheduler. Send accepts a bounded delay; longer horizons are a scheduler's job — keep the appointment in your database and send when it's due.
These tools compose: put Spooler next to them for the queueing.