Skip to content
Story & Structure
Work About Us
Contact

Scaling.

Build for the Traffic You Want, Not Just the Traffic You Have

Your Craft site handles today's traffic fine. But what happens when you launch in new markets? When a campaign drives 10x your normal visitors? When Black Friday arrives, and your commerce platform needs to handle hundreds of concurrent checkouts? When a product goes viral, and your server gets hit with more requests in an hour than it usually sees in a week?

Scaling is the engineering work that answers these questions before they become emergencies. It's the difference between a platform that grows with your business and one that becomes the bottleneck.

Talk to us About Scale

Why Craft Sites Hit Walls

Craft runs beautifully on a single server for most traffic levels. But single-server architectures have hard limits. When concurrent users exceed what one machine can handle, response times degrade for everyone. When the database becomes the bottleneck, there's no way to add more processing power without migrating to a larger server. When a traffic spike arrives, there's no capacity buffer.

Most Craft sites don't need to think about this. But if you're running commerce, serving international audiences, handling spiky traffic patterns, or growing quickly, you'll hit the wall eventually. The question is whether you hit it during a sales event with thousands of customers watching, or whether you've already engineered around it.

We've scaled Craft sites from single-server setups to multi-region, auto-scaling architectures serving millions of requests. The path depends on your traffic patterns, your budget, and how much complexity your team can operate.

What We Build

01

Horizontal Scaling

Moving from a single server to a multi-server architecture changes the fundamental characteristics of your platform. Request processing is distributed across multiple application servers. No single server failure takes down the site. Capacity can be added incrementally as traffic grows.

We architect horizontal scaling for Craft with careful attention to the challenges it introduces: shared session management, file-based asset synchronization, database connection pooling, and deployment coordination across multiple servers. Craft wasn't designed with horizontal scaling as a first-class concern, so the implementation requires specific expertise in how Craft handles state, caching, and file storage.

02

Caching Architecture

The most cost-effective scaling strategy is serving requests without hitting your application at all. A well-designed caching architecture can absorb 80-95% of your traffic at the CDN and reverse proxy layers, meaning your Craft servers only handle the requests that genuinely need dynamic processing.

We design multi-layer caching strategies: CDN edge caching for static assets and full-page responses, reverse proxy caching (Varnish or Nginx FastCGI cache) for dynamic pages with predictable cache lifetimes, application-level caching through Craft's built-in cache and Redis, and database query caching for expensive operations. Each layer has its own invalidation strategy so content updates propagate quickly without sacrificing cache effectiveness.

For commerce sites, caching is more nuanced—product pages can be cached aggressively, but cart and checkout flows are inherently dynamic. We design hybrid strategies that cache what can be cached and optimize what can't.

03

Load Balancing

Load balancing distributes incoming traffic across your application servers intelligently. Not just round-robin distribution, but health-aware routing that detects unhealthy servers and removes them from rotation, sticky sessions when needed for stateful operations, and connection draining during deployments so active requests complete before servers are replaced.

We configure load balancing at the infrastructure level (AWS ALB, Google Cloud Load Balancing, or HAProxy) with health checks tuned to Craft's specific behavior, SSL termination for efficient HTTPS handling, and WebSocket support for real-time features.

04

Auto-Scaling

Auto-scaling dynamically adjusts your infrastructure based on real-time demand. When traffic spikes, new application servers spin up automatically. When traffic subsides, they scale back down so you're not paying for idle capacity.

We implement auto-scaling with realistic scaling policies—not just CPU thresholds, but metrics that actually correlate with user experience like response time and request queue depth. We account for Craft's warm-up time (cache priming, OPcache population) so newly scaled servers are ready to handle traffic immediately, not serving slow requests while they warm up.

Scaling FAQ

  • 01

    At what traffic level do we need to think about scaling?

    There's no universal threshold—it depends on your page complexity, server specs, and caching effectiveness. A well-optimized Craft site on a decent server with good caching can handle thousands of concurrent users. But if you're seeing response time degradation during peak hours, if your server regularly exceeds 70% CPU, or if you're planning for significant traffic growth, it's time to think about scaling. Our technical audit can assess your current headroom.

  • 02

    Should we optimize first or scale first?

    Optimize first, almost always. Scaling an unoptimized application just spreads the inefficiency across more servers. A single database query that takes 500ms on every page load is still going to take 500ms on four servers—you're just paying four times the hosting cost to serve the same slow pages to more people. We typically do a round of performance optimization before any scaling work.

  • 03

    How much does scaling infrastructure cost?

    It varies widely based on the approach. Adding a CDN and caching layer (often the highest-impact, lowest-cost scaling move) might add $50-200/month. A full horizontal scaling setup with load balancing and multiple application servers starts around $500-1,000/month and scales up from there. Auto-scaling means you pay for capacity when you use it. We'll design an architecture that matches your traffic patterns and budget.

  • 04

    Can we scale without re-architecting our entire site?

    Usually, yes. The most impactful scaling improvements—CDN configuration, caching layers, and database optimization—can be added to an existing Craft site without code changes. Horizontal scaling requires some architectural adjustments (session handling, asset storage), but these are targeted changes, not a full rebuild. We take an incremental approach.

  • 05

    What about database scaling?

    Database scaling is typically the hardest piece. Read replicas can distribute query load. Connection pooling reduces overhead. Query optimization reduces per-query cost. For most Craft sites, these measures are sufficient. True database sharding or distributed databases are rarely necessary—and if we think you need them, we'll have a frank conversation about whether Craft is still the right tool for your data volume.

  • 06

    How do you test scaling before we need it?

    Load testing. We simulate realistic traffic patterns at multiples of your current volume and observe how the infrastructure responds. This reveals bottlenecks, breaking points, and scaling behavior before real users experience them. We test before deploying scaling changes and again after to validate the improvements.

Get Started

Ready to Build Something Exceptional?

Tell us about your project. Whether you're starting fresh, scaling up, or rescuing something that's gone sideways - we'll give you an honest assessment, not a sales pitch.

Start a Conversation