I am, for better or worse, a "heavy user" of the McDonald's app. And unfortunately, all this architecture somehow still misses so many usability issues. The most annoying one, is that the app always defaults to the closest location "as the bird flies." Despite the fact that I have "favorited" a different store, and also my last 5 or 10 orders were placed at this favorite store, the app ALWAYS defaults to the first store, which may be a tenth of a mile closer but has three additional traffic lights and twice the traffic.
The app is also wildly inaccurate with store open/close times (in both directions -- sometimes it tells you a 24-hour store is "currently closed"), and the in-store employees are often confused how to ring up or serve a mobile order.
But the deals are good. BOGO QPCheese just about every day.
> The most annoying one, is that the app always defaults to the closest location "as the bird flies."
I've got a similar annoyance with basically every app or website that offers to find things within N miles of me. I live in Western Washington on the other side of Puget Sound from Seattle.
Say the first two options they give me for N are 10 miles and 25 miles.
10 miles is too small. I need more than that to include Bremerton, Silverdale, and Poulsbo, which are the three most likely places that I'll find whatever I'm looking for if it exists over here.
But 25 miles means the circle reaches past Puget Sound and includes Seattle, Bellevue, and even some of Redmond.
For example if I'm searching for Target stores and enter my zip code, their search lists my nearest store first, then 13 stores on the Seattle side (5 in Seattle, 2 in Bellevue, and 1 each in Lynnwood, Everett, Redmond, Renton, Tukwila, and Woodinville) before the store that is actually second closest to me as far as actually driving goes (Gig Harbor).
Even the best event / data streaming architecture (or, more generally, a backend architecture) in the universe can be negated by a lousy frontend app / frontend layer architecture. I have never ordered anything from a Macca's… but I surmise that is the consequences that McDonald app users are facing.
The article lacks any details material to the event streaming architecture instantiation, and defers the details to a follow-up blog post, so it is hard to draw meaningful conclusions from it.
The one and only time I've used the app was when I thought it would help them during the pandemic when drive thru's were actually slammed with demand while they didn't have enough workers. After waiting in the parking lot for 30 minutes while literally dozens of cars went through the drive through I went in to check on the order and the employees literally couldn't look up the status of my order without an order number which the app didn't give me at the time. An incredibly frustrating experience which turned me off to the concept altogether.
> The most annoying one, is that the app always defaults to the closest location "as the bird flies."
So many apps do this and it's really annoying. There are quite a lot of commercial activity on the other side of the river from where I live, and every store's site I visit, or app I use, always recommends a couple of locations that are closest "as the bird flies", but require me to take a ferry, or drive an hour and a half, whereas the store that's actually the quickest to get to for me is just 15 minutes away from me in the next town over on my side of the river.
It's understandable though, because it's so much easier to calculate straight line distance, and I guess in most cases it gives the right, or close to the right answer. I've just accepted that I live in an edge case area for how the majority of commerces calculates these things.
No concerns about privacy issues? The Canadian iOS version of the app insists on running in background and complains of you disable precise location. This is slimy.
Both my partner and I always have trouble with the McDonald's app (for ordering). I use Android, she uses iOS. As a developer, I've said to myself "This feels like a React Native app that's calling into a mess of microservices" (having worked on that type of project more than once myself).
Anyway, I only skimmed the article, but I had a chuckle seeing the title of this article pop up on HN at all.
I can't speak for other region's McDonald's apps, but the mymacca's app (Australia) is entirely native Java on Android, and still runs like absolute crap.
Completely unrelated probably but who knows but this reminded me of the time when my McDonald's receipt printout from that self-ordering terminal started with a bunch of XML, then the regular receipt part and then ended in a bunch of XML. That was fun.
Did AWS just pay them to write this? I was hoping for an interesting article exploring the complexities of a massively distributed and high-throughout system, but I just read “we connected these managed AWS services together and it’s cool”
Hopefully further instalments might actually talk about the problems they faced building this out, and their unique challenges.
This is part of their technical blog ( https://medium.com/mcdonalds-technical-blog ), which looks like an outreach attempt to help with recruitment (hackathons etc). Probably someone went to a PM saying "we need to talk about our stack, how do we make it sound sexy and cool?" and this is what they got back.
> Standby Event Store: To avoid loss of messages in the event the MSK is unavailable, the platform is wired with a standby data store, where it writes events onto a database . The architecture provides tools and utilities to read messages and publish them back onto MSK, once it’s available.
on one hand aws msk is good enough for an enormous application like mcdonald’s. on the other they need a backup database just to get around it not being available? what’s the real story here. interested to see where this goes
Probably nothing more than a requirement for resiliency. With thousands of restaurants, chances of a couple of them losing connectivity each day are going to be pretty good, through traditional interruptions like backhoes digging up cables and drunk drivers taking out telephone poles.
If those messages are discarded because the store can't talk to MSK (or MSK is unavailable), then things like automatic replenishment based on order volume couldn't happen. The store manager would have to do a daily physical inventory count to know how many bags of fries, boxes of drink straws, etc. to reorder.
Cloud services do go down and it's out of your control when they do. If something must work, you need redundancy.
Kafka is often used for financial applications that must not miss events, so having a backup buffer is a reasonable strategy for those use cases. Things like tracking data is likely not worth backing up due to high data volume and low external visibility when data is dropped.
We use kinesis a lot at work, and some services are architected to write events to a Postgres table which eventually gets dumped to kinesis, while other services write directly to kinesis.
Guess which services fared better during the last kinesis outage?
Really, their app is a mess, but from a delivery point of view their stuff is pretty good.
Just yesterday I was going to redeem a deal and the store was closed to walk-ins, so I had to use the drive thru. I couldn't use the deal anymore because I had used the code already, and you can't apparently switch between walk in/drive thru mode. Luckily the drive-thru was so slow I was able to use the code (there's a timer on the code).
That said, the backend worked great; I ordered on the mobile in-line and the order was in-store once I got to the drive thru order speaker.
People forget how hard and expensive it was 10 years ago to do a realtime architecture. Today, McD gets information from your phone to wherever and down to the stores with maybe a few seconds of delay, so you can use your code at the in-store kiosk. And it has to integrate with their in-store order and payment systems.
I'm disappointed at the article, because it doesn't talk about any of this stuff; it's just a laundry list of AWS services. That isn't the important stuff; the important stuff is really how they got all this legacy (in-store) and new stuff to work together.
But I’m always shocked for some inexplicable reason to hear that places like McDonalds and Walmart Labs are interested in solving tech problems. But I mean obviously, of course they are.
Good to be reminded now and then that there are alternatives to contributing to the ad/social media panopticon, right?
It is often an OKR for senior/staff developers to write blogs or tech articles to promote the companies engineering culture, especially for organisations that are not 'traditional' tech firms.
I have a hunch that's part of it. I also think they're trying to show that they're as technically competent as Chik-fil-A, who has been doing this for a while now.
Recruitment but also retention. Some engineers want to publicly communicate their work at a recognizable company, or aspire to become the kind of company good enough to have a well-liked engineering blog. Providing that opportunity doesn’t cost much and means a lot.
From the company's perspective, the hoped for result is mostly recruiting oriented, a little bit is related to offering career advancement (public visibility of your work) to individuals that write or are featured in the blog.
That's all it is. These EDA transformation journey blog posts are de rigeur for any company looking to have its engineering culture perceived in a modern light, at least in the eyes of a junior-to-intermediate developer.
Is it really scalable? Every time the local McDonald's have some cross-promotion going on with a certain boy band (for example this week's collectable cards), their app's backend always crash right at 11am when the promotion starts.
I find this blog post to be a funny snapshot of how event driven architecture initiatives can be sold internally. “Oh it’s going to give us all these great advantages and be super robust and performant. Here’s my diagram of producers and consumers with our new event gateway project in the middle. How does it actually work? Um… I’ll tell you later”
In your monolith if you offload a request to a queue and have a background process processing the queue messages, what do you call that module processing messages? Is it a component of your monolith? I think a lot of teams would call it a microservice, I could see some people considering it a component of a service.
Unless you're confounding microservices w/ async architectures and saying to drop asynchronous patterns like this all together.
>with globally distributed teams of developers with diverse skill levels
The last place I worked with a monolith (~100 developers) put quite a bit of work into making sure everyone didn't step on everyone else's toes. This mostly propagated as optimizing CI and improving test quality (since a single flakey test could derail everyone's build)
As to why "microservices" versus a few "normal" sized services
I'm not sure why it's always "monolith" or "microservices"
[+] [-] andy800|3 years ago|reply
The app is also wildly inaccurate with store open/close times (in both directions -- sometimes it tells you a 24-hour store is "currently closed"), and the in-store employees are often confused how to ring up or serve a mobile order.
But the deals are good. BOGO QPCheese just about every day.
[+] [-] wincy|3 years ago|reply
After you order and drive away, I’ll find the app hours later still tracking me and using GPS. I almost always have to force close the app.
Then the next time I use it the previous order won’t have cleared out despite me picking it up, and I’ll have to go in and “cancel” the order.
The coupons are good though. For a week or two it was giving 30% off, and almost always has a 20% off coupon.
[+] [-] tzs|3 years ago|reply
I've got a similar annoyance with basically every app or website that offers to find things within N miles of me. I live in Western Washington on the other side of Puget Sound from Seattle.
Say the first two options they give me for N are 10 miles and 25 miles.
10 miles is too small. I need more than that to include Bremerton, Silverdale, and Poulsbo, which are the three most likely places that I'll find whatever I'm looking for if it exists over here.
But 25 miles means the circle reaches past Puget Sound and includes Seattle, Bellevue, and even some of Redmond.
For example if I'm searching for Target stores and enter my zip code, their search lists my nearest store first, then 13 stores on the Seattle side (5 in Seattle, 2 in Bellevue, and 1 each in Lynnwood, Everett, Redmond, Renton, Tukwila, and Woodinville) before the store that is actually second closest to me as far as actually driving goes (Gig Harbor).
[+] [-] inkyoto|3 years ago|reply
The article lacks any details material to the event streaming architecture instantiation, and defers the details to a follow-up blog post, so it is hard to draw meaningful conclusions from it.
[+] [-] tstrimple|3 years ago|reply
[+] [-] kaashif|3 years ago|reply
I always find this phrase funny. Isn't buying one and getting one the normal state of affairs?
[+] [-] wkjagt|3 years ago|reply
So many apps do this and it's really annoying. There are quite a lot of commercial activity on the other side of the river from where I live, and every store's site I visit, or app I use, always recommends a couple of locations that are closest "as the bird flies", but require me to take a ferry, or drive an hour and a half, whereas the store that's actually the quickest to get to for me is just 15 minutes away from me in the next town over on my side of the river.
It's understandable though, because it's so much easier to calculate straight line distance, and I guess in most cases it gives the right, or close to the right answer. I've just accepted that I live in an edge case area for how the majority of commerces calculates these things.
[+] [-] user3939382|3 years ago|reply
> Hi do you have a mobile order today?
< Yes.
> Inexplicable silence for 10-15 seconds
> (New voice) How can I help you?
< Hi I’m picking up a mobile order (??)
> What’s the code?
Their process of using the app at the drive through is missing a step and it’s annoying.
[+] [-] xattt|3 years ago|reply
[+] [-] rbosinger|3 years ago|reply
Anyway, I only skimmed the article, but I had a chuckle seeing the title of this article pop up on HN at all.
[+] [-] russelg|3 years ago|reply
[+] [-] tharkun__|3 years ago|reply
[+] [-] halfer53|3 years ago|reply
https://www.plexure.com/
not sure what their architecture is
[+] [-] geysersam|3 years ago|reply
It's a form. What's the problem?
[+] [-] tom_walters|3 years ago|reply
Hopefully further instalments might actually talk about the problems they faced building this out, and their unique challenges.
[+] [-] toyg|3 years ago|reply
This is part of their technical blog ( https://medium.com/mcdonalds-technical-blog ), which looks like an outreach attempt to help with recruitment (hackathons etc). Probably someone went to a PM saying "we need to talk about our stack, how do we make it sound sexy and cool?" and this is what they got back.
[+] [-] foolfoolz|3 years ago|reply
on one hand aws msk is good enough for an enormous application like mcdonald’s. on the other they need a backup database just to get around it not being available? what’s the real story here. interested to see where this goes
[+] [-] chiph|3 years ago|reply
If those messages are discarded because the store can't talk to MSK (or MSK is unavailable), then things like automatic replenishment based on order volume couldn't happen. The store manager would have to do a daily physical inventory count to know how many bags of fries, boxes of drink straws, etc. to reorder.
[+] [-] nick0garvey|3 years ago|reply
Kafka is often used for financial applications that must not miss events, so having a backup buffer is a reasonable strategy for those use cases. Things like tracking data is likely not worth backing up due to high data volume and low external visibility when data is dropped.
[+] [-] hamandcheese|3 years ago|reply
Guess which services fared better during the last kinesis outage?
[+] [-] manv1|3 years ago|reply
Just yesterday I was going to redeem a deal and the store was closed to walk-ins, so I had to use the drive thru. I couldn't use the deal anymore because I had used the code already, and you can't apparently switch between walk in/drive thru mode. Luckily the drive-thru was so slow I was able to use the code (there's a timer on the code).
That said, the backend worked great; I ordered on the mobile in-line and the order was in-store once I got to the drive thru order speaker.
People forget how hard and expensive it was 10 years ago to do a realtime architecture. Today, McD gets information from your phone to wherever and down to the stores with maybe a few seconds of delay, so you can use your code at the in-store kiosk. And it has to integrate with their in-store order and payment systems.
I'm disappointed at the article, because it doesn't talk about any of this stuff; it's just a laundry list of AWS services. That isn't the important stuff; the important stuff is really how they got all this legacy (in-store) and new stuff to work together.
[+] [-] achrono|3 years ago|reply
Is this a recruitment tactic somehow for such companies?
[+] [-] bee_rider|3 years ago|reply
But I’m always shocked for some inexplicable reason to hear that places like McDonalds and Walmart Labs are interested in solving tech problems. But I mean obviously, of course they are.
Good to be reminded now and then that there are alternatives to contributing to the ad/social media panopticon, right?
[+] [-] dbetteridge|3 years ago|reply
[+] [-] joezydeco|3 years ago|reply
https://medium.com/chick-fil-atech
[+] [-] annoyingnoob|3 years ago|reply
From what I can tell the career path is into Corporate hell.
https://www.uopeople.edu/blog/hamburger-education-inside-mcd...
[+] [-] 1123581321|3 years ago|reply
[+] [-] cco|3 years ago|reply
[+] [-] itisit|3 years ago|reply
[+] [-] spacehunt|3 years ago|reply
[+] [-] mark_sz|3 years ago|reply
So it doesn't matter what architecture is behind McD systems if customer facing software doesn't work correctly.
[+] [-] j-bos|3 years ago|reply
[+] [-] keepquestioning|3 years ago|reply
[+] [-] nycdotnet|3 years ago|reply
[+] [-] georgeburdell|3 years ago|reply
[+] [-] barbarbar|3 years ago|reply
[+] [-] guyzero|3 years ago|reply
[+] [-] alanhaha|3 years ago|reply
[+] [-] lokar|3 years ago|reply
[+] [-] marcosdumay|3 years ago|reply
[+] [-] b20000|3 years ago|reply
also, when are those ice cream machines going to get fixed?
[+] [-] toomuchtodo|3 years ago|reply
Thread: https://threadreaderapp.com/thread/1597983918900510720.html
[+] [-] ramenmeal|3 years ago|reply
Unless you're confounding microservices w/ async architectures and saying to drop asynchronous patterns like this all together.
[+] [-] nijave|3 years ago|reply
The last place I worked with a monolith (~100 developers) put quite a bit of work into making sure everyone didn't step on everyone else's toes. This mostly propagated as optimizing CI and improving test quality (since a single flakey test could derail everyone's build)
As to why "microservices" versus a few "normal" sized services
I'm not sure why it's always "monolith" or "microservices"
[+] [-] kemiller2002|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] nathanaldensr|3 years ago|reply
[+] [-] dboreham|3 years ago|reply
[+] [-] itake|3 years ago|reply
[+] [-] campbel|3 years ago|reply