14 ms·

My rule of thumb is: First build it with a database, then break things off using NoSQL/Queues/Memfs/etc. after scale increases to a point where it becomes a pai

My rule of thumb is: First build it with a database, then break things off using NoSQL/Queues/Memfs/etc. after scale increases to a point where it becomes a pain. Its never a good idea to start something built in the most optimized way possible (in terms of performance). In my experience 99% of the time, actual performance numbers are way less than what you expected anyways.

craigching 12y ago
I don't consider using a messaging system if you need messaging premature optimization at all. That's just using the right tool for the job.
- vidarh 12y ago
  "Messaging" and "messaging system" is too nebulous. Why are you not using a mail server? I'm totally serious. Been there, done that (used qmail as a message bus). It works great for certain types of requirements. Sometimes you badly need persistence. Sometimes it doesn't matter. Sometimes you need massive scalability. Sometimes you need reporting. Sometimes you need to be able to provide a dashboard to visualize pending messages. Sometimes you need to be able to publish to large numbers of listeners at once. Sometimes a small number of listeners needs to aggregate events from thousands or millions of sources. Sometimes you need a message to only be processed exactly once. Often you can nail down some of those issues from the outset. As well as scale. But often you won't know in advance. More importantly: Your system will almost certainly use a database server. Unless you have clear indications that your needs can't be met by the database server, adding a "messaging system" is one more dependency which you don't yet know whether or not you'll actually need. One more thing that can fail.
  - craigching 12y ago
    > Why are you not using a mail server? If that's the right tool for the job, then I wouldn't argue with you. But my messaging needs are typically solved by tools like WebSphere MQ, RabbitMQ, etc.
nacs 12y ago
I don't see how this applies to messaging systems at all. It's actually harder to implement a real-time messaging system with a database or key/value store than it is to use something like RabbitMQ (messaging) or Beanstalkd (for jobs).

craigching 12y ago

I don't consider using a messaging system if you need messaging premature optimization at all. That's just using the right tool for the job.

vidarh 12y ago
"Messaging" and "messaging system" is too nebulous. Why are you not using a mail server? I'm totally serious. Been there, done that (used qmail as a message bus). It works great for certain types of requirements. Sometimes you badly need persistence. Sometimes it doesn't matter. Sometimes you need massive scalability. Sometimes you need reporting. Sometimes you need to be able to provide a dashboard to visualize pending messages. Sometimes you need to be able to publish to large numbers of listeners at once. Sometimes a small number of listeners needs to aggregate events from thousands or millions of sources. Sometimes you need a message to only be processed exactly once. Often you can nail down some of those issues from the outset. As well as scale. But often you won't know in advance. More importantly: Your system will almost certainly use a database server. Unless you have clear indications that your needs can't be met by the database server, adding a "messaging system" is one more dependency which you don't yet know whether or not you'll actually need. One more thing that can fail.
- craigching 12y ago
  > Why are you not using a mail server? If that's the right tool for the job, then I wouldn't argue with you. But my messaging needs are typically solved by tools like WebSphere MQ, RabbitMQ, etc.

nacs 12y ago

I don't see how this applies to messaging systems at all. It's actually harder to implement a real-time messaging system with a database or key/value store than it is to use something like RabbitMQ (messaging) or Beanstalkd (for jobs).