Write the queries down first
Write down the five queries your system will run most, with rough volumes, before you name a single product.
Fetch a cart by user, 2,000 a second. Search product text, 400 a second. Place an order touching stock and payment, 50 a second. Once that list exists the choice is close to mechanical. Before it exists, no choice is defensible.
Three questions per query
Ask three things of each query on the list. Does it need to change several records together? Money, stock, bookings, anything where two records must move as one, wants a relational store.
Does anyone need to ask questions you have not thought of yet? Reporting and admin screens want SQL.
Does the write volume beat what one leader can take? Below a few thousand a second, one relational database with read copies is fine and you should stop overthinking it. At hundreds of thousands you are in wide-column territory whatever your heart says.
Freshness cuts next. the data must be. If slightly stale reads are harmless, a feed, a view count, a catalogue, then eventual consistency buys you cheap scale. If they are not harmless, the stores that trade consistency for availability will hurt you in ways that arrive as customer tickets rather than error logs.
What your team can operate filters last. Three people running their own wide-column cluster will spend a sad fraction of their lives on repairs and upgrades. A managed service changes that arithmetic, which is a perfectly good reason to pick one product over a technically similar one.
The honest default is worth keeping in your pocket: a relational database until one specific query pattern breaks it, then one specialist for that pattern only. Saying that sentence in an interview and defending the single specialist you added beats any exotic architecture you could draw.
Worked example
A three-engineer marketplace team debates their stack for two weeks. One engineer, Tobias, pushes MongoDB everywhere for iteration speed. The lead, Ines, forces the query-list exercise instead. The list: product page by id (1,200 per second), text search (300 per second), add to cart (150 per second), checkout with inventory decrement (20 per second), seller revenue dashboard (rare, complex). Checkout needs a transaction across orders, inventory, and payments, which settles the core store: Postgres. Search gets Elasticsearch fed from Postgres, because ILIKE queries were already timing out in the prototype at 200,000 products. Carts land in Redis with a 30-day TTL. Total: three stores, each doing the one thing it is best at, and the entire debate took an afternoon once the queries were on the whiteboard.