4 ms·

I'd guess that 100x database interactions per order may be more like it. Upon startup, there's a whole login, check app version, payment cards still valid, geo

I'd guess that 100x database interactions per order may be more like it. Upon startup, there's a whole login, check app version, payment cards still valid, geo query sequence. Check user's point total, rewards, custom offers. Load menu based on chosen store availability and prices. Every menu item has multiple options (mcnugget sauce, burgers without tomato, type of soda). Add to cart. Remove from cart. Add something different to cart. Repeat. Ok, order ready? Check taxes in local jurisdiction. Adjust total based on offers/rewards. Delivery or pickup? Pickup in-store, curbside, drive-thru? Communicate order to store. Update order status based on customer arrival. Send code to customer. Update status upon pickup/delivery. Lots more in-between I skipped, and that's just user-facing, nothing about analytics, accounting, loyalty club, etc. I'm not defending McDonald's or it's architecture -- as I stated elsewhere, the app is far from perfect, and an entirely different architecture could very easily work much better. But I do think you are severely downplaying the number of interactions or transactions required to run an app like theirs.

BoorishBears 4y ago
I mean you wrote all this justification, but 30k per second is still practically nothing compared to the complexity described in the article? Taking something like Postgres and sprinkling in some strategic use of Redis would handle their usecase with horizontal scaling pretty reliably... What it wouldn't do is let you add Kafka to your resume.
- andy800 4y ago
  To be clear, I was not justifying the current architecture, I specifically wrote "an entirely different architecture could very easily work much better." I was pointing out, however, that, as is often the case, the initial estimates in a typical "why do they need all this stuff" post, likely underestimated the transaction volume by possibly 10x. Perhaps 3000 or 30000 transactions per second could run on the same system -- I'm not an expert at that scale. But I doubt you'd find any Fortune 100 company relying solely on Postgres and Redis.
  - BoorishBears 4y ago
    I mean if you got nitpicky 3000 or 30000 transactions doesn't tell you anything... but in this kind of evaluation you need to think dimensionally. That's why I intentionally assumed all of their traffic shows up in one contiguous block of 8 hrs across all locations every day: that added a massive fudge factor even bigger than the number you're focusing on... > But I doubt you'd find any Fortune 100 company relying solely on Postgres and Redis. I mean, yeah? Across every system they use of course that wouldn't be it: what would be generating the data that goes into them? Where would the data that goes in be going out? I'm simply referring to their "glue" for day to day operations, which here is a pubsub system built on Kafka. Most organizations of a certain size start to pick up some set of technology that new efforts default to being built on top of if only to have access to what everyone else is doing... that's essentially what AWS started off as before it was spun out from internal usage - But more importantly, Fortune 100 is a very random pairing of problem spaces. I mean you won't find any built solely on Postgres and Redis for the very obvious reason I mentioned above... but you will find billions of dollars in revenue on even more boring stuff than that. The number of Oracle shops using repackaged technology that makes Postgres look like Cloud Spanner is staggering. I find the opposite of what you do, that people tend to overestimate what it takes to handle large amounts of data reliably. And I think it's because you need some experience with this stuff to understand why you can't just think in terms of "underestimated the transaction volume by possibly 10x"(hint: 10x can mean 3 million => 30 million). What happens is people hear that system A is going to need to go from 3,000 to 30,000, then start to architecture the way someone going from 3 million to 30 million should have, and suddenly you're building out a system that's less reliable, more expensive, and just generally worse except for what shows up on resumes.

BoorishBears 4y ago

I mean you wrote all this justification, but 30k per second is still practically nothing compared to the complexity described in the article? Taking something like Postgres and sprinkling in some strategic use of Redis would handle their usecase with horizontal scaling pretty reliably... What it wouldn't do is let you add Kafka to your resume.

andy800 4y ago
To be clear, I was not justifying the current architecture, I specifically wrote "an entirely different architecture could very easily work much better." I was pointing out, however, that, as is often the case, the initial estimates in a typical "why do they need all this stuff" post, likely underestimated the transaction volume by possibly 10x. Perhaps 3000 or 30000 transactions per second could run on the same system -- I'm not an expert at that scale. But I doubt you'd find any Fortune 100 company relying solely on Postgres and Redis.
- BoorishBears 4y ago
  I mean if you got nitpicky 3000 or 30000 transactions doesn't tell you anything... but in this kind of evaluation you need to think dimensionally. That's why I intentionally assumed all of their traffic shows up in one contiguous block of 8 hrs across all locations every day: that added a massive fudge factor even bigger than the number you're focusing on... > But I doubt you'd find any Fortune 100 company relying solely on Postgres and Redis. I mean, yeah? Across every system they use of course that wouldn't be it: what would be generating the data that goes into them? Where would the data that goes in be going out? I'm simply referring to their "glue" for day to day operations, which here is a pubsub system built on Kafka. Most organizations of a certain size start to pick up some set of technology that new efforts default to being built on top of if only to have access to what everyone else is doing... that's essentially what AWS started off as before it was spun out from internal usage - But more importantly, Fortune 100 is a very random pairing of problem spaces. I mean you won't find any built solely on Postgres and Redis for the very obvious reason I mentioned above... but you will find billions of dollars in revenue on even more boring stuff than that. The number of Oracle shops using repackaged technology that makes Postgres look like Cloud Spanner is staggering. I find the opposite of what you do, that people tend to overestimate what it takes to handle large amounts of data reliably. And I think it's because you need some experience with this stuff to understand why you can't just think in terms of "underestimated the transaction volume by possibly 10x"(hint: 10x can mean 3 million => 30 million). What happens is people hear that system A is going to need to go from 3,000 to 30,000, then start to architecture the way someone going from 3 million to 30 million should have, and suddenly you're building out a system that's less reliable, more expensive, and just generally worse except for what shows up on resumes.