If you sell anything under pressure (tickets, drops, bookings, limited stock) you've had the conversation about making the site scale. It usually ends one of two ways. Re-platform, or bolt something on and hope.
Neither is much of an answer. One is expensive, slow and risky. The other is a pile of point solutions installed under duress, generally the week before an on-sale.
There's a third option, and it's been in our product the whole time. We've rebuilt it, and it's live in your control panel today.
We started with a reverse proxy. Then we watched it quietly win.
The first CrowdHandler was a reverse proxy. Point it at any website and you got a queue that couldn't be bypassed, with no code integration whatsoever. No plugin. No SDK. Just DNS.
When we relaunched as self-serve SaaS in 2021, that looked like the old way of doing things. More clients were running their own CDNs, and when there's already an edge in place, dropping a worker into it beats chaining another proxy in front of it. So we shipped a family of edge and SDK integrations and let people pick whatever suited their stack. The DNS implementation stayed in the lineup for anyone who wanted something fast and non-bypassable.
Then it quietly became one of the most reliable things we run. It sits in front of your infrastructure rather than inside it, so your server never carries the cost of checking and redirecting users, and years of what we've learned about scale live in our layer instead of your codebase. For most WordPress sites it's a better integration than our WordPress plugin. We're aware of how that sounds.
Setup now assumes you've already got something in front of you
Onboarding is a guided three-step flow: certificate issued, origin set, CrowdHandler enabled.
We've also reworked it for a case that turns out to be very common --- running our DNS implementation behind another reverse proxy, Imperva more often than not. If you're stacking us on top of an existing WAF or security layer, the setup understands that from the first screen, rather than from the third support ticket.
Cache the window. Queue the till.
This is the one that matters.
Every site is really two sites. Your marketing content is identical for every visitor and scales almost for free once it's cached. Your transactional funnel --- cart, checkout, booking --- is unique per user, database-heavy, and never truly scalable. Treat them as one thing and you inherit the worst properties of both.
Appcelerator now lets you draw that line at the URL level, from the control panel. Set a behaviour rule and your landing page serves from the AWS point of presence nearest the visitor. No queue check. No wait. No round trip to your origin. For most people the page arrives faster than your own server could ever manage.
Step into a purchase or booking path and you're checked in with the queue, and those pages are served uncached, as they have to be.
It sounds simple. Separating marketing concerns from transactional ones is the whole game in scalable web architecture, and most teams learn it the hard way, during an on-sale, at ten in the morning. The difference here is that you can apply it retrospectively --- to a site nobody designed that way --- through a reverse proxy and a control panel, instead of a replatforming project.
The queue is the visible feature. The scalability is the product.
If you think of us as the queue people, Appcelerator looks like an easier way to install a queue. It is that.
But look at what it does on an ordinary day, with no on-sale and no queue running. It serves your cacheable content from AWS edge locations worldwide, every one of them closer to your users than your origin is. It absorbs traffic your server never sees. It holds a live picture of your site's performance. And it stands ready to meter access to your transactional pathways the moment they come under pressure.
Because it all runs through one layer, the parts feed each other. The cache lowers the load reaching your origin. A lighter origin sustains a higher transaction rate. A higher transaction rate means the queue admits people faster, which means shorter waits --- or, on a quiet day, no queue at all. Meanwhile the same layer is watching response times on the pathways that matter, so when demand does spike, the admit rate reflects what your site can genuinely handle right now, rather than a number someone guessed in a planning meeting.
What you're actually turning on
A non-bypassable queue. CDN-grade caching for the content that should be cached. Queue-protected transactions for the pathways that need it. Continuous performance measurement. No code integration.
Point your DNS at us, and the architecture you should have had gets applied in front of the one you've actually got. Your origin doesn't need to know it's happening. Your CMS doesn't need a plugin. Your developers don't need to be involved beyond approving a DNS change.
It's live today
Appcelerator is in your control panel now, under your domain's deployment settings.
If you're on our WordPress plugin, or you've been putting off a proper integration because it looked like an engineering project, it's worth ten minutes of your time. And if you'd like a hand working out which of your URLs belong on which side of the cache/queue line, talk to us --- it's a conversation we enjoy.
Got an on-sale, a drop or a campaign coming that might test all this? Sign up to CrowdHandler for free.