The 95/5 rule: what read-heavy really means for spend

Every application that talks to a database does two kinds of work: it reads rows and it writes rows. Writes are what most people picture when they think of a database. A customer places an order, a user updates a profile, a sensor logs a reading. Reads are everything else, and everything else is most of it.

For a typical business application the split is somewhere around 95 reads to 5 writes. The exact ratio varies, but the shape does not. Even applications that consider themselves write-heavy tend to read each row many times for every time they change it.

Where the reads come from

Reads are not mostly the big reports. They are the small, constant requests behind every click: is this user allowed to see this page, what is their name and plan, what are the twenty items on this list, how many rows are there in total. A single screen can fire a dozen of them, and a single user can open hundreds of screens in a session.

• Permission and session checks, on nearly every request.
• Profile, settings and configuration loads.
• List pages, search results and detail views.
• Counts, totals and lookups that feed other requests.

None of these is expensive on its own; a fast database answers each one in a few milliseconds. The cost is in the volume. Millions of small reads a day add up to a database that is busy all the time, and a busy database is a database that needs the next tier.

What a database tier is actually sized for

When a team picks a database tier, it is choosing enough processing power, memory and connections to answer its busiest hour. That hour is dominated by reads, because reads are 95% of the traffic and because busy hours are busy with people looking at things, not changing them.

So the tier is, in effect, a read-serving budget. The writes ride along inside it and would fit comfortably in a much smaller box. This is the part that is easy to miss: the expensive engine is being bought to do the cheap kind of work, at volume.

A database tier is priced for the 95%, and most of the 95% never needed a database.

What changes when reads come from memory

Now suppose the reads are answered from a memory cache (Redis, which keeps data in memory rather than on disk) that is kept in step with the database as rows change. The 95% moves off the database. What remains for the database is the 5% of writes, plus one more thing that matters: the ability to take the reads back if the cache is ever unreachable.

That fallback is why the database does not shrink to nothing. It has to be sized for writes plus a realistic fallback share, not for writes alone. In practice that still lands well below where it was, which is where the figure of roughly 70% off the database line comes from. It is not 95% because the fallback headroom is real and we keep it.

The memory cache adds a line to the bill, but memory for the rows in active use costs less than a database engine sized for every read, and it grows in small steps rather than doublings.

What it means for peak days

The 95/5 split gets more extreme on the days that matter. On a peak shopping day, or the last day of a reporting period, the number of people looking at things climbs far faster than the number of things being changed. Browsing outpaces buying by a wide margin. The peak is a read peak.

That is why peak days are usually what force a database upgrade, and it is why moving reads into memory changes the peak-day conversation. When reads are absorbed by the cache, the database sees a write peak, which is a fraction of the read peak. We have handled peak shopping days with the database at 99% of its processing and memory capacity and kept serving.

What it means for the bill

Put the pieces together and the shape of the saving becomes clear.

1. The database tier drops to what writes plus fallback need.
2. Growth in users mostly adds reads, so it is the cache that has to grow, not the database tier.
3. The peak-season upgrade, the one that was bought for a read peak, is no longer forced by reads.
4. The cache line that appears in its place is smaller than the database line it replaced.

Nothing about the rows themselves changes. The database is still the source of truth, still takes every write, and still holds every row. It has simply stopped being the thing that answers every question.

redfly is one way to make that move without changing the application: reads served from a memory cache that redfly keeps in sync with your database, writes going straight through, and reads falling back to the database automatically if the cache is unavailable.