Queue Lab is a queue-benchmark harness: the same notification fan-out workload run through multiple queue backends behind one explicit messaging contract, compared on latency, throughput, loss, backlog, retry, and ordering from real runs. Only the messaging adapter changes per backend, so the differences you observe are the queues' own, not the application's. The deliverable isn't a large codebase — it's a defensible set of measured findings.
- Problem: "Which message backend survives slow consumers and bursty load?" is usually answered by folklore. Queue Lab answers it with evidence — comparison tables and failure write-ups from real runs, rather than vendor promises.
- Design: One fan-out pipeline (ingest an event, expand it into one delivery per subscriber, deliver each) runs unchanged across every backend; only the
MessageBusimplementation is swapped. Two intentional bus crossings — aneventstopic and adeliveriestopic — let celebrity fan-out (one event exploding into thousands of deliveries) show up without blocking ingestion. - Backends: Currently runs across an in-memory bus, Redis Pub/Sub, and Kafka, each behind a capability-gated contract test it must pass. RabbitMQ, SQS, Kinesis, and Google Pub/Sub are the planned next axes (pull-based, AMQP, and managed-throttling behavior).
- Honest measurement: Loss is computed from the edge, not from a backend's own counters — every event and delivery carries a stable id, and loss and duplicates are derived from expected-versus-observed ids in a result ledger. Delivery is at-least-once with a deterministic idempotency key; the harness never claims end-to-end exactly-once.
- Key finding: Under a sustained slow consumer, Redis Pub/Sub dropped ~93% of deliveries while Kafka lost none, holding them as backlog — a concrete illustration of best-effort push versus a durable log.
- Stack & reproducibility: Java 17 and Spring Boot, with Testcontainers integration tests running against real Redis and Kafka so the findings reproduce with a single
./mvnw verify.