Back to Codex
Scaling Ecommerce When Traffic Spikes 10x Overnight
Feb 24, 2026
Bookshop.org launched in January 2020. Six weeks later, the world locked down.
Traffic that was supposed to ramp up over months arrived in days. Independent bookstores across the country closed their physical locations and sent customers to Bookshop, where they could still purchase books and the stores would still earn a commission. The platform went from promising newcomer to critical infrastructure for an entire industry segment almost overnight.
Most new ecommerce sites would have buckled. Bookshop scaled to over 2 million monthly visitors and processed $65 million in sales during its first year. The difference came down to decisions made before anyone knew a pandemic was coming.
Why Most New Ecommerce Sites Aren't Ready for Scale
There's a common pattern in ecommerce development: optimize for launch, worry about scale later. Teams focus on getting to market quickly, which makes sense because revenue at zero is a more immediate problem than theoretical future traffic. Infrastructure investments feel like premature optimization when you're not sure anyone will show up.
The problem is that later sometimes arrives without warning. It can look like a mention on a popular podcast, a viral social media moment, or even a global event that reshapes buying behavior overnight. When that happens, sites built for "good enough for now" performance start throwing errors, dropping transactions, and losing customers who won't come back.
Bookshop faced a version of this challenge from day one, though not because of anticipated viral growth. Their mission was to compete with Amazon for online book sales while funneling profits back to independent bookstores. That meant there was no room for the kind of performance issues that might be tolerable for a smaller operation. Customers choosing Bookshop over Amazon needed the experience to feel just as reliable. Slow load times or checkout failures would send them right back.
So the architecture had to be built for scale from the start, even when the traffic numbers didn't yet justify it.
Architecture Decisions That Paid Off
The first major decision was platform selection. Shopify would have been faster to launch, and it's a reasonable choice for many ecommerce businesses, especially those with straightforward product catalogs and standard checkout flows. But Bookshop's business model wasn't standard. They needed to track affiliate relationships with hundreds of independent bookstores, each earning commission on sales attributed to them. They needed deep integration with book industry data systems. They needed flexibility to build features that didn't exist in any off-the-shelf solution.
We built the platform on Solidus, an open-source ecommerce framework built on Ruby on Rails. Solidus gave us full control over every aspect of the commerce experience while providing battle-tested foundations for cart management, checkout flows, and order processing. The tradeoff was more upfront development work, but the payoff was a system that could be customized exactly to Bookshop's requirements.
Hosting went on Google Cloud with containerized infrastructure. This matters for scaling because containers can spin up and down based on demand. When traffic spikes, additional instances come online automatically. When traffic subsides, they scale back down. The system breathes with the load rather than running at fixed capacity and hoping for the best.
For catalog search, we implemented Elasticsearch rather than relying on database queries. This decision might seem like overkill for a bookstore, but consider the scale: millions of titles, each with metadata for author, publisher, format, subject categories, and more. Users expect to search by partial title, author name, ISBN, or vague recollections of what a book was about. They expect results in milliseconds. SQL databases start to struggle with this kind of workload at scale, especially when you add filtering, sorting, and faceted navigation. Elasticsearch was purpose-built for exactly these use cases.
The Ingram Integration Challenge
The technical challenge that doesn't show up in most ecommerce architecture discussions is third-party data integration. Bookshop needed to import and maintain a catalog of millions of titles from Ingram Content Group, the largest book distributor in the United States. Ingram's systems were built to serve physical bookstores and traditional publishing workflows. Integrating with a modern web platform required bridging two very different technical worlds.
Data arrives from Ingram as fixed-width text files transmitted via FTP. Some of these files exceed 15 gigabytes uncompressed. They contain product information, inventory levels, pricing, and metadata in formats designed decades ago for batch processing systems. Different files refresh on different schedules. The files are interdependent: you need category data before you can properly process title data, and you need title data before you can attach cover images.
We built a tiered ingestion system to handle this. A large processing instance receives the files and splits them into manageable chunks. Smaller worker instances pick up these chunks as background jobs through Sidekiq, a Redis-backed job processor. Each chunk gets validated, transformed into the format our system expects, and posted to the Solidus application via internal APIs. The sequencing is critical: categories process before titles, titles before images, everything in the right order so relationships are preserved.
This architecture handles the normal case of nightly data refreshes. It also handles the abnormal case of needing to reprocess the entire catalog, which happens more often than you'd expect when upstream data formats change or when you need to add new fields to your product records.
The key insight here is that third-party integrations deserve the same architectural attention as customer-facing features. An unreliable data pipeline means incorrect prices, missing products, or stale inventory. Customers see the symptoms even if they never know the cause.
What Happened When COVID Hit
In early March 2020, independent bookstores started closing their doors. Owners who had built their businesses around community events, hand-selling, and personal recommendations suddenly had no way to reach customers. Many faced the real possibility of permanent closure.
Bookshop became a lifeline. Stores could create affiliate pages, share links with their customers, and earn 30% commission on any resulting sales. For readers who wanted to support local bookstores but couldn't visit in person, Bookshop was the obvious choice. Traffic didn't just increase. It exploded.
The systems held. Pages loaded quickly. Checkouts completed successfully. Orders flowed through to fulfillment. The same infrastructure decisions that seemed like over-engineering in January proved essential in March.
Within the first few months of the pandemic, Bookshop had raised over $5 million for independent bookstores through affiliate commissions. By the end of the first year, that number was much higher, and the platform had established itself as a permanent part of the book industry's landscape.
None of this would have been possible if the technical foundation had required emergency rebuilding during the traffic surge. You can't fix scalability problems while you're drowning in them.
Lessons for Building Scalable Ecommerce
The Bookshop story offers several principles that apply beyond bookselling:
Invest in infrastructure before you need it. The cost of over-provisioning is predictable and manageable. The cost of downtime during a traffic spike includes lost sales, damaged reputation, and customers who form their first impression during your worst moment. If your ecommerce business matters, build it like it matters.
Choose platforms that give you room to customize. Off-the-shelf solutions work well for standard use cases. If your business model has any complexity, you'll eventually hit the walls of what those platforms can do. Starting with a flexible foundation costs more upfront but prevents expensive migrations later.
Treat third-party integrations as first-class architectural concerns. Data pipelines, API connections, and external dependencies can become your biggest reliability risks. Design them with the same care you'd give to your checkout flow.
Build monitoring and alerting from day one. You can't fix problems you can't see. Instrumentation isn't a nice-to-have for later; it's how you know whether your system is healthy and how you catch issues before customers do.
Plan for the traffic you want, not just the traffic you have. If your business plan involves growth, your architecture should accommodate that growth without requiring a rebuild. This doesn't mean gold-plating everything from the start. It means making choices that leave room for scaling rather than choices that assume current traffic levels are permanent.
Bookshop didn't know a pandemic was coming. But they built their platform as if success was coming, which meant they were ready when circumstances accelerated their timeline dramatically.
We partnered with Bookshop.org from their earliest days to build a platform that could compete with the biggest names in online retail while supporting independent bookstores nationwide. Read the full case study to learn more about the technical and strategic decisions behind the platform.
Building an ecommerce platform that needs to handle unpredictable traffic? Let's talk about what we've learned.
Written by: Keaton Brown
Edited by: Milos Roganovic
Reviewed by: Holly Zappa
Let's chat
