3 ms·
Right, but I do believe that it is important to choose something that scales competently: > most won't ever reach the point where they need such a thing I con
by zamalek 3y ago
Right, but I do believe that it is important to choose something that scales competently:
> most won't ever reach the point where they need such a thing
I considered covering this argument in my gp comment. What if your startup does grow to the scale where it becomes an issue? Do you suspend new user signups until you can do the rewrite? Or do you just let things keep spiraling, like GitHub? Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite).
- gls2ro 3y agoI agree about making an informed choice. I disagree with: > Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite). How can this be true when we know that Shopify, Gitlab, Github and all others are using RoR. Here is a more concrete scale[1]: > We served 75.98 Million requests per minute to our commerce platform at peak. That’s 1.27 Million requests per second! Is that a bit enough limit for you? Here is more: > We achieved 99.999+% uptime while averaging 3 Terabytes per minute of egress traffic across our infrastructure [2] [1] https://twitter.com/shopifyeng/status/1597983926126977024 https://twitter.com/shopifyeng/status/1597983926126977024 [2] https://twitter.com/shopifyeng/status/1597983918900510720 https://twitter.com/shopifyeng/status/1597983918900510720
- kirso 3y agoThe assertion that the startup will achieve this scale is the main pitfall here imo, the chance is less than 0.01%. By the time you reach this problem, you'll have an army of developers to take care of this.