nkraft11

4 ms·

1. 1.▲
   by nkraft11 1y ago

   Sort of. In this case the lack of multithreading led engineers to using sidekiq as a stand in.
2. 2.▲
   by nkraft11 1y ago

   You're totally correct. It's not a problem of ruby per se, but engineers would basically just throw their hands up and say "ruby can't handle this" and sidekiq became the One True Way™. What ensued was the most byza
3. 3.▲
   by nkraft11 1y ago

   Error handling was a huge issue, along with other weird distributed system bugs. Backed up queues, job shedding, thundering herds, you name it. When you have jobs on queues kicking off new jobs on different queues, tracing issues is just mi
4. 4.▲
   by nkraft11 1y ago

   I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But th
5. 5.▲
   by nkraft11 1y ago

   I can say that going from a place that had all of that observability tooling set up to one that was at the "ssh'ing into a box and greping a log" stage, you best believe I missed company A immensely. Even knowing which box to