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 an EDD licensing server

Serverless computing is a relatively new concept. Outside Ymir and its customers, there hasn’t been a lot of interest around it in the WordPress community. Part of it is distrust around the term “serverless” and what it really implies compared to hosting WordPress with a server.

But part of it is just not knowing what serverless is good at. Serverless is the best technology for scaling an application and doing so quickly. That’s why it’s an amazing technology for hosting e-commerce WordPress sites using WooCommerce or Easy Digital Downloads (EDD). I’ve written about WooCommerce before, but the entire article also applies to EDD as well.

That said, a lot of people know and use EDD for a specific use case: software licensing. Their software licensing extension is very popular with paid plugin authors. It saves them the time and energy to develop their own licensing system. (A complex endeavour for anyone!)

While a licensing server isn’t an e-commerce site per se, it still suffers from similar issues as an e-commerce site. That’s why serverless is also a perfect technological solution for anyone self-hosting their own EDD licensing server.

Let’s dive into why that is.

License validation requests aren’t cacheable

This is the first part of the problem. When EDD sends a license validation request, it does so using the POST request. And this POST request isn’t cacheable.

That’s because, as per the HTTP spec, a POST request isn’t idempotent. When a request isn’t idempotent, it means that, if you repeat the same request, the response to the request might not be the same from one request to the next. A simple example of this is, if you submit a POST request for a form and do it again, you’ll get two entries for that form and not one. That’s why you often see a prompt with “Do you want to submit this form again?”

Now, EDD is absolutely correct to use a POST request to send a license validation request. This isn’t a request that should be idempotent. You could send a request to validate a license one minute before it expires. If you sent the same request a minute later, the response would be different. This is also why you shouldn’t cache license validation requests.

I say “should” here because EDD lets you switch the license validation requests from a POST request to a GET request. A GET request is idempotent and thus cacheable.

That said, while it’s possible to do that and cache the responses to these requests, it’s not officially recommended or documented. HTTP caching is tricky (one of the two hard things in programming!) and varies from host to host. This means that, unless you know HTTP caching and your host very well, you can end up caching a valid or invalid license response for a long time! (Some HTTP caches cache GET request responses for a year!)

That’s why this article assumes you’re not doing that. But, if you know HTTP caching and your EDD hosting setup inside out, you should look into it!

Why are uncacheable requests bad?

Ok, so you might wonder, “What does it matter if license validation request aren’t cacheable?” Well, from a hosting perspective, it matters a lot! Below is a diagram showing a pretty standard architecture for WordPress hosting.

You can see that the “page cache” (this is another term often used interchangeably with HTTP cache) sits in front of the server. The primary goal of this cache is to limit the number of requests that hit PHP on the server. Any request that reaches PHP is slower to process and also more taxing for the server to handle.

The latter is really what causes problems when you can’t cache requests. PHP can only handle so many requests at a time before the server starts to buckle. And when that happens to your licensing server, your plugin won’t be able to validate if the license is active or not. Depending on how you handle that, this might cause issue for your customers and increase support tickets.

Now, it’s worth mentioning that EDD tries to mitigate this scenario as much as it can. If you use the EDD_SL_Plugin_Updater (you can learn how to use the class here), if it’s unable to contact the licensing server to validate the license, it waits another hour before trying again. The software licensing API also supports checking the license of multiple products at once.

License validation traffic is spiky and unpredictable

At this point, we understand why EDD license validation requests aren’t cacheable and the impact those uncached requests have on a server. To mitigate these issues, you need a server powerful enough to handle the peak license validation traffic. The problem is that this is very hard to plan for because license validation traffic is very uneven and the spikes are hard to predict.

That said, you can plan for some spike scenarios. For example, you should see a lot of license validation traffic when:

  • A new plugin update causes a lot of plugins to phone home
  • Lots of new customers sign up because of a sale (e.g. Black Friday)

But even knowing that a spike is coming, it’s still hard to know how powerful you need the server to be. And, once you figured that out, you’re still stuck paying for that powerful server even if it’s not doing anything 90% of the time. That’s because you never know (outside a few predictable scenarios) when you’ll have a license validation traffic spike.

How does serverless help with all this?

Took a little while to get to this! But it’s important to understand the underlying issues that make hosting an EDD licensing server challenging. Now, we can look at why a serverless WordPress solution like Ymir helps with this problem.

Now, I have to do my due diligence and say that there are still servers with serverless. The point of serverless is to remove servers as something you have to worry about. This is also what you’re looking for when you pay for managed WordPress hosting.

The big difference between the two is that with serverless you don’t have to worry about the power of your server either. With managed WordPress hosting, if your server is underpowered and you get a huge traffic spike, there’s a good chance the server will go down. You can upgrade to a larger plan, but the hosting company won’t automatically do it for you while your server is on fire.

With serverless, whenever your cloud provider receives an uncached PHP request (as we discussed earlier), it spins up a small server to process it. Once the response to that request gets sent back, that small server gets shutdown and destroyed. This is all done automatically for you in fractions of a second.

The amazing thing with serverless is that there’s essentially no limit to how many of these small servers you can have. So let’s say suddenly you go from receiving a few license validation requests to receiving hundreds. Your cloud provider (Amazon Web Services (AWS) with Ymir) will create hundreds of these small servers in an instant to handle this traffic.

Above is what your serverless WordPress architecture would look like. It’s very similar to the architecture we saw earlier. The difference is that there isn’t just one server handling PHP requests now, but an infinite number of them.

This makes spikes in license validation requests irrelevant.

Serverless keeps your critical business infrastructure up and running

A licensing server is an essential part of any WordPress plugin or theme business. But as a system that relies on uncached PHP requests, an EDD licensing server is especially vulnerable to traffic spikes. And if it goes down, it can cause you a lot of headaches.

With serverless, you don’t have to worry about your EDD licensing server anymore. It’ll stay up regardless of how much uncached traffic it receives. So you can release a new plugin version or do a sale without worrying whether it’ll stay up.

That’s the peace of mind you get with serverless.