Every few years someone rediscovers that the filesystem — that boring, decades-old abstraction sitting under everything — is actually a remarkably capable primitive. SteadQ appears to be one of those rediscoveries, and based on the title alone it deserves a closer look from anyone who has ever wrestled with Kafka, RabbitMQ, or SQS just to move a few messages between processes.

The premise is deceptively simple: use directories and files as the queue itself. This isn't a new idea — maildir has done it since the mid-1990s, and Postfix's queue directories work on similar principles — but modern developers rarely reach for it. Why bother running a message broker with its own persistence layer, network protocol, cluster coordination, and operational burden when the kernel already gives you:

• Atomic renames via rename(2) — the foundation of nearly every filesystem-as-queue design, guaranteeing a message either exists in its new location or doesn't
• Durable writes via fsync, with the same crash-consistency guarantees you'd want from any queue backend
• Free tooling — you can ls, grep, tail -f, or rsync your queue. Try that with Kafka.
• Zero operational overhead — no broker to monitor, upgrade, or scale. Backup is cp -r.

The tradeoffs are real: filesystem-based queues typically hit a wall at high throughput (inode contention, directory scan costs), and cross-machine coordination is where the model gets tricky — you're now depending on NFS semantics or whatever distributed filesystem you have. But for the enormous middle ground of "I need durable message passing between a handful of processes on one box, or a small cluster with shared storage," it's often the right answer and rarely the one chosen.

What makes this post particularly worth reading is that it's likely a working implementation, not just a manifesto. The interesting details will be in how it handles the classic pitfalls: consumer coordination without polling storms, dead-letter handling, ordering guarantees, and how it deals with the ext4/xfs/zfs behavioral differences that make "just use the filesystem" harder in practice than in theory.

In an era where every side project seems to ship with three databases and a Kubernetes cluster, articles that reach for boring, battle-tested primitives are a reminder that the best infrastructure is often the infrastructure you already have.