3 ms·

operationally, makes sense. but the inevitable moment (if you survive) you need to migrate to smth else depending on a different queue system, it'll be a pain t

by chucke 5y ago

operationally, makes sense. but the inevitable moment (if you survive) you need to migrate to smth else depending on a different queue system, it'll be a pain to retrofit the code relying on db-level transactions and locks.

Nextgrid 5y ago
This only makes sense if the effort to migrate is more than the accumulated effort of working with and maintaining that solution from the start.
- azurelake 5y ago
  The effort to use something like SQS is almost nothing.
xupybd 5y ago
The if you survive but is key. If you survive to the point you need to scale like this you will no doubt have more resources available. Do what you can to get going now. Solve future problems as they come.
bcrosby95 5y ago
Except it's not inevitable. We have a few 15+ year old profitable projects that are still working fine on RDBMS backed queues.
jjav 5y ago
> but the inevitable moment (if you survive) It's probably not inevitable. Simple is fast, and fast can scale you really far. Sure, if you end up being google-scale then yeah, the world changes. But there's very few companies that large, yours is probably not growing to that size. Over a decade ago I joined a mid-sized startup and took ownership of a service using MySQL. The first urgent warnings I was given was that they had to migrate to cassandra ASAP because soon MySQL couldn't possibly handle it. I took a look at the traffic and the growth curve and projected customer adoption. And then put that project on hold, no need yet. Company went on to an IPO, grew a lot, pretty successful in its industry. And years later when I left, it was still going strong on MySQL with no hint of approaching any limitations.
- azurelake 5y ago
  There's a pretty big spread between google-scale and needing to use a "real" queue instead of a RDBMS though. I honestly think you're better off using something like SQS to start with and taking the very minimal ops burden of the extra dependency.

by chucke 5y ago

Nextgrid 5y ago

This only makes sense if the effort to migrate is more than the accumulated effort of working with and maintaining that solution from the start.

azurelake 5y ago
The effort to use something like SQS is almost nothing.

xupybd 5y ago

The if you survive but is key. If you survive to the point you need to scale like this you will no doubt have more resources available. Do what you can to get going now. Solve future problems as they come.

bcrosby95 5y ago

Except it's not inevitable. We have a few 15+ year old profitable projects that are still working fine on RDBMS backed queues.

jjav 5y ago

> but the inevitable moment (if you survive) It's probably not inevitable. Simple is fast, and fast can scale you really far. Sure, if you end up being google-scale then yeah, the world changes. But there's very few companies that large, yours is probably not growing to that size. Over a decade ago I joined a mid-sized startup and took ownership of a service using MySQL. The first urgent warnings I was given was that they had to migrate to cassandra ASAP because soon MySQL couldn't possibly handle it. I took a look at the traffic and the growth curve and projected customer adoption. And then put that project on hold, no need yet. Company went on to an IPO, grew a lot, pretty successful in its industry. And years later when I left, it was still going strong on MySQL with no hint of approaching any limitations.

azurelake 5y ago
There's a pretty big spread between google-scale and needing to use a "real" queue instead of a RDBMS though. I honestly think you're better off using something like SQS to start with and taking the very minimal ops burden of the extra dependency.