A marketplace's product database has become the bottleneck for a read-heavy workload. The team proposes sharding immediately. What lower-complexity options should be exhausted first, and in what order?

The ladder, cheapest first

1. Find the actual queries. In most read-heavy bottlenecks a handful of query shapes account for the majority of load, and at least one of them is doing something accidentally expensive — a missing index, an unbounded IN list, an N+1 from an ORM, a SELECT * pulling a large text column into every list view. This step is usually the largest single win and it costs a day.
2. Index for the real access patterns. Covering indexes for the hot queries, and — just as important — dropping indexes nobody uses, since every one of them taxes writes.
3. Cache the hot set. Marketplace traffic is extremely skewed: a small fraction of products generates most of the views. A cache exploits skew disproportionately well, which is not true of a uniform workload.
4. Read replicas, once the cache is in place, for the long tail. This buys transparent read scale at the cost of replication lag and read-your-own-writes anomalies, which must then be handled explicitly for the flows where they matter — a seller editing their own listing.
5. Denormalise the read path. A materialised product view assembled asynchronously removes joins entirely for the listing and search paths.
6. Then shard, if the write volume or the working-set size genuinely exceeds one machine.

Why the order matters

Each step is roughly an order of magnitude cheaper to build and operate than the next. Sharding is the most expensive option on every axis — it complicates every query that crosses a shard, breaks cross-shard transactions, makes schema migrations a distributed operation, and turns rebalancing into a permanent operational responsibility.

It also cannot be undone easily, so a team that shards prematurely carries the complexity for the life of the system whether or not it was needed.

The question that decides it

Is this read-bound or write-bound? Sharding primarily helps write throughput and working-set size. If the problem is reads, sharding adds enormous complexity to solve a problem that replicas and caches solve for a fraction of the effort. A team that cannot answer this from data should not be choosing between the options at all.

The evidence that would justify sharding

Write throughput approaching the ceiling of the largest available instance · a working set that no longer fits in memory on one machine and where the cache hit rate is already high · a table so large that maintenance operations exceed their windows · or a regulatory requirement to keep certain rows in a specific jurisdiction, which is a partitioning requirement regardless of load.