[aurareturn]

It was one of the top real estate portals in the world. A lot of geolocation searches. New search every time someone moves the map. A ton of data sent to the client. Analytics in every page view.

No clue how a shopping cart or checkout flow would drastically increase database load. It should just be basic CRUD. Building a shopping cart is something every student makes. Pages in a web store can be cached relatively easily since items won't change often.

A primary DB with a few replicas and caching can go a really long way.

[chatmasta]

The composition of the average transaction will be different in a shopping cart (lots of writes and updates) compared to your use case which sounds like it skewed read heavy. With Postgres it’s generally easier to scale reads because it doesn’t really matter which replica the query hits, as long as it contains the data it needs. Whereas write-heavy workloads route through a single-writer bottleneck.

There’s challenges scaling read-heavy workloads, for sure — but they’re generally more straight forward than scaling write-heavy workloads. You can get away with more dumb horizontal scaling than with writes.

[willdr]

You don't see how adding functionality that requires writing to the database rather than just reading from a cache could "drastically increase database load"?

[aurareturn]

Even if it's writing to the DB, I doubt basic queries like adding an item to a cart is going to need DB sharding.

I think one piece that someone else mentioned could require DB sharding and that is all the live data needed for tracking deliveries.

The actual website/app should not need more than one beefy Postgres instance.