Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You don't even need a database to make a message queue. The Linux file system makes a perfectly good basis for a message queue since file moves are atomic.

My guess is that many people are implementing queuing mechanisms just for sending email.

You can see how this works in Arnie SMTP buffer server, a super simple queue just for emails, no database at all, just the file system.

https://github.com/bootrino/arniesmtpbufferserver



This is true, and I’ve worked on systems that use this, but it’s a lot more work than just a rename.

I’d recommend that, if you have a Postgres database already, definitely use that instead. Your queues will be transactional and they will get backed up when the rest of your database does.


>> but it’s a lot more work than just a rename

Such as?


Well, if you have multiple writers then you need to decide who’s responsible for rotating the queues, and you need to serialise writes; or if each writer has its own queue then the reader has to do more work. And then you need to worry about fsync, and backup. And of course you need to be careful to flush to the queue after each write to avoid partial writes.

Basically I’m saying that there are just a number of potential footguns when using files as queues - I speak from experience! - which are trivially taken care of by a database, especially if you have one already.

I’m not saying that it’s not possible, just that for non trivial applications, it’s certainly more complex than just an atomic file move.


Detecting broken files when your application crashed half-way through a write; coordinating id generation.


That’s a key property leveraged in the Maildir mailbox format.


It was learning about this that led to me understanding file systems make perfectly acceptable queues.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: