6 ms·
100k(s) orders per minute is several orders of magnitude more than realistic. Amazon does 20k orders per minute. Instacart doesn't need "100,000s of grocery de
by tomtomtom777 3mo ago
100k(s) orders per minute is several orders of magnitude more than realistic. Amazon does 20k orders per minute.
Instacart doesn't need "100,000s of grocery delivery orders per minute".
There must be some 0s added for the sake of the story.
- true_religion 3mo agoAccording their 2026 Q1 filing they do about 90 million orders per quarter which is about 12 orders per second, 720 orders per minute. It might make 100k row level changes per minute, but that’s a different metric. https://www.sec.gov/Archives/edgar/data/1579091/000157909126000032/q12026pressrelease.htm https://www.sec.gov/Archives/edgar/data/1579091/000157909126...
- gaucheph 3mo agoi think this assumes that those orders are distributed evenly over time
- andriy_koval 3mo agoit could be peak orders per second
- ktm5j 3mo agoI'd wager on this.
- tomtomtom777 3mo agoGoing from 720 average to 100,000s peak still doesn't sound realistic. especially as they operate in many timezones.
- FinnKuhn 3mo agoInstacard 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. [1] https://www.kaggle.com/datasets/psparks/instacart-market-basket-analysis https://www.kaggle.com/datasets/psparks/instacart-market-bas... [2] https://rstudio-pubs-static.s3.amazonaws.com/284199_5c498037acc64051862e0829c2702ce5.html https://rstudio-pubs-static.s3.amazonaws.com/284199_5c498037...
- aeyes 3mo agoThis data set was released years before the Covid hypergrowth phase which they are referring to.
- FinnKuhn 3mo agoThat'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. [1] https://www.kaggle.com/datasets/psparks/instacart-market-bas https://www.kaggle.com/datasets/psparks/instacart-market-bas... [2] https://fortune.com/2022/05/18/what-to-know-instacart-ipo/ https://fortune.com/2022/05/18/what-to-know-instacart-ipo/
- deleted 3mo ago[deleted]
- willio58 3mo agoAnd just like that you’ve done more due diligence than the VCs who just threw money at this.
- UqWBcuFx6NV4r 3mo agoNope. Completely flawed logic that assumes equal distribution. Dunning Kruger
- true_religion 3mo agoI thought not assuming uniform distribution was table stakes for senior engineers. I can't say what the curve looks like, but 100,000 orders per second would consume reach official quarterly count in 15 minutes. Since that's unlikely, this at least gives us some degree of bounds to guess what the curve looks like.
- dotancohen 3mo agoAmazon does 20k peak, or 20k average? Website visitor peaks could easily be two orders of magnitude higher traffic than average for a few minutes.
- aurareturn 3mo agoI 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.
- dotancohen 3mo agoYes, but that's not a shopping cart, or a checkout workflow, nor a web store with heavy analytics.
- aurareturn 3mo agoIt 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 3mo agoThe 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.
- nijave 3mo agoThat 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