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

I really cannot stand the idea of making message queues that speak the memcache protocol. That's like having a RDBMS that only speaks HTTP.

Memcache is an impoverished language for messaging. Which is ok, because it's designed primarily for cache fetch and retrieval. Just like you wouldn't really want to go fiddling around with database cursors through HTTP (looking at you, freebase) you don't want to describe queueing and delivery of your messages over memcache.

And it's not like there aren't alternatives. Stomp is a perfectly acceptable protocol for simple messaging. If you need to do something fancy and complicated, there is also AMQP. Both protocols are supported by mature servers that are proven to run in highly available production systems. So why, other than a case of NIH, would a company want to spend time writing and supporting one off infrastructure like that?



It is interesting that a relatively advanced piece of software, message queues, which most run of the mill projects most likely have no need for, has an interface that is compatible with a simple, straightforward protocol that was designed for everyone and their dog. I mean, if you need message queuing, you most likely have someone on staff who can design, write, and deploy a protocol language (especially if they can write the queuing software also) and who doesn't need to use compatibility libraries.

Great, your memcached-compatible queuing service can leverage all those memcached client libraries out there, but somehow I don't think that client libraries are the hard part of the queuing service.


But what if you don't need a full RDBMS but all the nice characteristics of a REST interface? Think about CouchDB and friends.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: