3 ms·
Higher uptime and more computation, although this was mostly C# so very efficiently run code. It was an e-commerce site doing +100MM a year. There was little t
by atonse 7y ago
Higher uptime and more computation, although this was mostly C# so very efficiently run code. It was an e-commerce site doing +100MM a year.
There was little to no room for error. I once introduced a bug in a commit that, in less than an hour, cost us $40,000. So it wasn't about performance.
Also this was 9 years ago. So adjust for performance characteristics from back then.
- dwild 7y ago100 000 000$ a year with only 20 requests a second? That's some crazy revenue per request, 100 000 000 / (365 * 24 * 60 * 60) = 3.17$ per request! What were you selling?
- atonse 7y agoInsurance policies :) Good point, actually the 100MM may have included brick and mortar.
- mytherin 7y agoForgot to multiply by 20, it's actually around $0.15 per request. Still high but certainly not as crazy.
- aaron_m04 7y agoIt should be (365 * 24 * 60 * 60 * 20) which brings it to $0.15/req if I did my mental math right. Still a high amount of course.
- dwild 7y agoOh thanks, I actually did the math right the first time, kept only the result and then when I was about to hit send I thought it was too good to be true, thus I did it again and got 3.15$, which was even crazier, but couldn't find why my math was wrong.
- btilly 7y agoI worked on a site 20 years ago that got even better revenue per request (though with fewer requests). It did analytics on bond deals. Cost $1k/month for an account. Minimum 3 accounts. Median logins, ~1/month/account. On the other hand people would login because they were about to trade $10-100 million of bonds. So knowing what the price should be really, really mattered. Wall St can be a funny place.
- dwild 7y agoThat's quite interesting! That's why I asked, I wasn't exactly doubting the figure, just curious about the market that allowed that kind of customer targeting.