Instacard have released a public dataset[1] on their orders, so it should be even easier to verify this claim. From what I could find in some analysis[2] of this dataset around 100k orders per day and not per minute seems accurate.
I assume they are referring to how many database requests they have due to customers orders or a similar metric and just worded it poorly.
That's fair as the Kaggle dataset[1] is from 2017. Even assuming orders scaled with revenue (which grew to $1.5B in 2020[2]), you'd only reach a few hundred orders/minute at the pandemic peak (which lines up with the calculation above via a different method).
So I still assume the original comment isn't referring to actual orders placed.
I worked at a company that had billions of views per year on a single big Postgres instance. Extremely read heavy with many queries needed for a page load. You can cache a lot of things.
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.
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.
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"?
That doesn't necessarily mean _new_ orders per minute. Their app or website could poll for updates every 15 seconds
Could just be looking at the "orders" endpoint in their app which might also include incremental updates as shoppers get items from the store. It's a fairly ambiguous statement
Is that still a lot? Feels like a single 64-core, 256GB RDS instance with some caching should handle that fine. RDS has instances up to 192-core and 768GB.
I think the real-time logistics is likely the thing taxes a Postgres database.
Everything else seems normal DB CRUD that a single beefy instance with a few replicas should handle easily. Type ahead search is no doubt using a different service and not directly querying Postgres.
Instacart doesn't need "100,000s of grocery delivery orders per minute".
There must be some 0s added for the sake of the story.