Keeping an online store fast as its catalogue grows.
Hita is an online store whose product range grew very large, with products nested in many categories. It needed work on its database to stop checkout from slowing down.
The situation
A young online store keeps its data simple: a list of products, their variants and the orders. Then Hita added wholesale price levels, stock across several warehouses and complex category filters, and the data became much more tangled.
On normal days it seemed fine. But during promotions and flash sales, product pages slowed to a crawl, shoppers abandoned their carts, and the database was pushed to its limit with requests queuing up.
The real problem
Every product page was doing too much work.
The problem was not just more visitors. Every page view had to pull data from many places at once: filtering products, working out category trees, checking stock in three warehouses and applying customer discounts.
As the catalogue grew, the database's usual shortcuts stopped helping. Even basic searches forced it to scan huge amounts of data.
What we did
We stopped the shop from gathering everything fresh on every page view, and reorganised how product data is read:
Ready-made product pages
We prepared simplified, ready-to-serve versions of the product data and kept them in fast memory. Browsing no longer competes with stock updates.
Faster database lookups
We studied the slowest requests and added the right shortcuts (database indexes), so the most common lookups no longer scan everything.
Refreshing only what changed
When the stock of one product changes, only that product's saved copy is refreshed, instead of clearing everything.
Safe stock holds at checkout
When many shoppers check out at the same moment, stock is held using a fast reservation system, so orders don't block each other.
The Result
Faster catalogue reads, and checkout that stays stable during promotional spikes.
Product listing pages went from multi-second loads to fast reads, and database load stayed steady through flash-sale traffic. Exact before-and-after figures are shared on request.
Some details are generalised to respect client confidentiality. Specific figures are shared on a call.
What we learned: not every page view needs the main database.
The main database is excellent at keeping orders and stock correct. It is poor at gathering data from many places for every page view. By separating reading from writing, a store can grow its catalogue without fearing slowdowns.
Is a slow database holding your product back?
Tell us what is going on. We will trace the slow requests with you.
Request an Architecture Review →