Heya, I'm Carl! I'm the solo founder of Ymir. Ymir is an open startup. You can view its up-to-date business metrics, and also sign up for a newsletter where you can learn how I'm building and marketing it. Check it out.

Why serverless is the perfect hosting solution for WooCommerce

Serverless computing isn’t discussed much in the WordPress community. But it has the potential to transform how WordPress sites scale and perform.

No WordPress platform has more to gain from serverless computing than WooCommerce. Hosting a WooCommerce site comes with unique challenges that you don’t have when hosting a regular WordPress site. That’s why a lot of managed WordPress hosting companies started to offer dedicated WooCommerce hosting.

Serverless is the perfect technological solution to tackle those challenges. That’s why you’ll probably start hearing more and more about it.

How do you host a regular WordPress site?

But before we go over the main issue with hosting WooCommerce sites, it would be useful to look at how you host a high traffic WordPress site. While the implementation can vary from host to host, the general architecture is essentially the same. It looks like the diagram below:

Whenever a browser makes a request for a WordPress page, the first thing that a WordPress host will try to do is serve a cached version of that page. If the WordPress host doesn’t do page caching, then you might have a caching plugin handling it. But, in general, a high performance WordPress site will have one.

The reason a WordPress host wants to use page caching is to reduce the number of requests that make it to PHP. PHP is a lot slower than serving a page using a page cache. It’s also a lot more taxing on the server.

This last bit is the important thing to keep in mind. A page cache can serve thousands of requests per minute without your server breaking a sweat. But because of its resource needs, PHP can only handle a fraction of that, even if you have a massive server.

So if these thousand of requests handled by the page cache went to PHP instead, it would take down the server. Which is what you often see if someone without a page cache receives a sudden burst of traffic. The site becomes unavailable.

But not all WordPress pages can use a page cache. For example, you can’t cache the WordPress login page or the admin. PHP has to be the one sending the response for these pages.

It’s all about the cart

This brings us to WooCommerce. The architecture for hosting a WooCommerce site looks exactly the same as the one for hosting a WordPress site. You have a page cache, PHP, a database.

The problem is the pages that a page cache can’t cache. More specifically, a certain part of the page: the cart. You can’t cache a cart because it’s unique to each visitor. And since the cart appears on every page, it means that you can’t cache a page once a cart isn’t empty.

This is why I mentioned the scenario about request suddenly going from the page cache to PHP. That’s exactly what happens when you add an item to a cart. The requests go from being served from the page cache to being served by PHP because the cart isn’t empty.

Now, this isn’t a big deal if you have a few people adding items to cart.

But what happens if there’s a sale? Well, you now have hundreds of people with items in their cart. Each cart can’t be cached so your number of PHP requests explodes takes down the server.

If you’re using a specialized WooCommerce host, they mitigate this scenario by giving you a larger server than you’d have with a regular WordPress site. This is one reason they charge more. That said, this only works as long as you don’t have any huge sales spikes.

If your WooCommerce site is more of the type to have those, you’re in a tough position. Either you’re paying for those potential spikes all the time. Or you’re not, and your site might go down during the most critical time in your business.

How does serverless tackle this problem?

So how does a serverless PHP solution like Ymir fix this issue?

It all comes down to the very nature of serverless computing. Now, the name serverless is misleading. There are still servers somewhere. You just don’t have to worry about them.

In theory, this isn’t very different from a managed WordPress host either. That said, there’s one big difference versus a managed WordPress host: it’s that you don’t have to worry about the power of your server either.

With serverless, each time you make a call to PHP, a small server gets created to process it. When PHP finishes processing the request, the server gets shut down unless there’s another request to process. This is all done automatically for you.

Now, if you’re receiving a high volume of requests, serverless computing will create as many servers as necessary to process them. This scaling happens automatically in seconds, and there aren’t any limits to how many of these PHP servers you can have.

Above is a simplified diagram of our serverless WordPress architecture. It’s very similar to our earlier architecture, but now we don’t have one server. Instead, we have an infinite pool of potential PHP servers to handle our traffic.

It’s easy to see how this architecture can help mitigate the cart issue when hosting a WooCommerce site. Since there’s no more “server”, you’re no longer limited by the number of requests PHP can handle. So if your WooCommerce site sees a spike in sales, your infrastructure will scale to handle the traffic.

Once that spike ends, everything scales back down. So you’re not stuck paying for a large server to handle those potential spikes or stressed wondering if your site will go down during a sale. It’s a weight off your shoulders and wallet!

Can’t you get a host that autoscales?

Container orchestration technologies such as Kubernetes are powerful platforms that offer similar infinite scaling potential. Some hosts have already started relying on it to scale their internal infrastructure. So you might be wonder how that technology compares.

The problem is that scaling with Kubernetes is a lot slower than with serverless. It relies on a cluster autoscaler to determine when to scale and add nodes. Since the autoscaler relies on resource signals to determine when to scale, this creates a lag in the scaling.

That’s why it takes, in the best-case scenario, about a minute for Kubernetes to spin up a new node. At worst, several minutes.

By the time that node comes up, it’s often too late. Your WooCommerce site has been unresponsive for a while. You’re also constantly trying to play catch up trying to match your infrastructure needs to the current demand.

AWS Lambda scales the moment a request cannot get processed. There’s still a cold start to the new Lambda which creates a bit of lag. That said, it’s a few seconds compared to minutes.

What about the database?

You probably noticed that we haven’t talked about the database yet. Unfortunately, while serverless databases exist, their cost and performance isn’t quite there yet. So while serverless will solve the problem with carts overwhelming your PHP server, the same isn’t true for databases. (At least, not yet!)

This means that we still have a similar problem as before. If you’re not careful, the PHP servers that serverless computing creates can overwhelm your database server. Does that mean that we’re out of luck?

No, of course not! This database problem is something hosting companies have to contend with as well. But the larger positive is that database servers are a lot more performant than a PHP server and harder to take down.

How hard are they to take down? Well, look no further than this Twitter thread discussing load testing done on WooCommerce running on AWS Lambda. The real kicker is this one:

A $13/month RDS database was able to handle at least 300 concurrent customers checking out at the same time with no object cache. You’d need a massive server with a lot of PHP workers to handle that much traffic. WordPress hosts will charge several hundred dollars per month for such a server.

But with serverless, you have access to it on demand, and you don’t have to pay for anything when there’s no traffic. So not only are you capable of handling massive traffic spikes, it’ll also cost you less to do so. (It’s not completly free because you still have the database to pay for.) It’s a win-win scenario!

A new beginning

Serverless is still in its early days. But seeing how it trivializes hosting server intensive platforms like WooCommerce is really mind-blowing.

If you run a WooCommerce store, you shouldn’t worry about your server whenever you have a spike in sales. You should have confidence that it can handle anything that you can throw at it.

With serverless, we’re closer to this than ever before.