Imagine a million transactions a month. Okay, 10 million. Assuming it’s a company that sells products, and the typical order size is $50, we’re talking of $500 million in monthly revenue. Or $6 billion annual. That’s big deal. Very few businesses reach that level.
Now, also asuume that the order flow is evenly distributed during the day; that is, there’s no radical spike in traffic (for instance, traffic doesn’t shoot up 200 times without warning).
Question: How many PHP servers would you need for this setup?
Now, 10 million transactions a month sounds mind-boggling. Let’s break it down. Per hour, this comes down to 10,000,000 / (30 * 24) ~= 13,800 transactions. Per second, it’s about 13,800 / 3,600 = 4 transactions.
4 transactions a second. That’s the typical load for a business making half a billion in revenue. Let’s double it: 8-10 transactions per second takes us to a monthly revenue of 1 billion!
Let’s compute the memory involved: 300 MB for the OS + 300 MB for PHP-FPM and Nginx + let’s say, 50 MB of memory per transaction (which is unlikely). So, we’re looking at around 1.1 GB of memory. Let’s also factor in unforeseen circumstances and jack that up to around 4 GB.
Now, what kind of server do you need to handle 10 transactions a second? Yes, a trivial one. A simple VPS costing around $20 a month can easily handle this traffic alone. If you want to be on the safe side, a $50/month VPS is all you need to run this setup.
Even if you have a load balanced setup, it’s hard to imagine how the monthly expense can exceed $150, inclusive of taxes (for servers alone, that is; we’re not taking account the cost of sending email, because it’s going to be the same on every backend).
I may be incorrect in my assumptions, but look at the big picture: $100 spent on infrastructure gives you $1 billion revenue’s worth of traffic-handling!
This is the reality of 99.9% of the projects out there. They’re going to grow, but they are rarely going to touch levels of more than a few transactions per second. Now imagine what a server with 32 GB of RAM can do! What about 64 GB RAM? I think you get the idea. 🙂
In other words, the debate of what is more “scalable” falls flat on its face in the real world. That’s why PHP is still going strong, and that’s why experienced PHP developers yawn when they hear “scalability”.
Node.is is a great choice, mind you. If you have a team comfortable with Node.js, by all means use that. I would even say that because of it’s real-time capabilities, Node is an overall better choice than PHP. However, discarding PHP just because you think you’ll run into scalability problems soon is like worrying about your pile of bricks reaching the moon: it’s not going to happen.