4 ms·
i worked on the backend for this rewrite, and it was even more extreme than the other write-ups suggest. we not only rewrote the apps, we also 1. moved from
by cancan 5y ago
i worked on the backend for this rewrite, and it was even more extreme than the other write-ups suggest. we not only rewrote the apps, we also
1. moved from email-based auth to phone-based auth
2. removed all the auth and onboarding logic from the clients and moved it over to server
3. changed the networking from a hacky OpenAPI/Swagger code to Thrift over HTTP
i am not saying it was the most conservative call to do all this at once but it was necessary. the auth logic was basically untenable and no one really knew how it worked. some team in amsterdam could (and did) lock down uber for android users in russia because they changed some code.
we also had to move to phone as a primary identifier, because honestly there are many countries people dont even use email. but how do you deal with phone numbers that were validated more than 7+ months ago, if you want to avoid things like this? [1] or how do you deal with promotions that required validating phone numbers not being VoIP that you could do out-of-band before but now have to do in-band?
anyway, i am being scatter minded here but it was probably one of the riskiest things uber did, from my point of view, changing the top of the funnel + also moving users from one auth to another with a download, esp given with apple's rollout mechanism we had no way back.
but it all worked! i should probably write this up one day.
1: https://arstechnica.com/information-technology/2016/02/when-phone-verification-and-recycled-numbers-collide-lyft-leaks-user-data/ https://arstechnica.com/information-technology/2016/02/when-...
- cghendrix 5y agoCan you expand upon the team in Amsterdam locking down Uber for people in Russia?
- tomnipotent 5y agoUber is in many markets, but has to serve them all from a single distribution. That leads to logic, screens, and workflows specific to each customers situation. I imagine it isn't difficult for one team to inadvertently affect another, given this constraint.
- cancan 5y agoi am being sorta vague here and taking some creative liberties with the markets involved. but at a high level, there was so much logic spread over various versions of the apps + geographies + some permutations of those. so you could add a check somewhere (app/server/both) like if (foo) and assume it'd not break in some markets, but lo-and-behold, if often did.
- gregdoesit 5y agoYeah, on my team (payments) we completely underestimated the backend complexity, assuming there would be little to no effort, and pulling in a backend engineer “just in case”. We ended up scrambling as it became apparent how many things changed (from polling to push notifications, thrift changes etc etc) and making the backend ready became a heroic effort itself... especially that we had very few backend engineers in Amsterdam at the time. You should write up your experience!!
- cancan 5y agoyeah, probably we annoyed the sh*t out of many payments folks as so much of the top of the funnel relied on things they should not have been doing. and the thrift changes, lol, that was something else. but it all worked out seems like. and honestly, if you consider how fast uber moves compared to its competitors, im willing to bet it was the right call now.
- sneak 5y ago> we also had to move to phone as a primary identifier, because honestly there are many countries people dont even use email. And I'm over here without a SIM card in my devices, and not using a telephone number at all.
- anirudhan 5y agodeal with phone numbers that were validated more than 7+ months ago, if you want to avoid things like this? [1] Can you expand on how apps handle this usecase?
- cancan 5y agoThe short answer is, you need to validate phone numbers every 6 months (which is the time phone operators keep the number closed when people change numbers) if you need 100% confidence that they are the real owners. This is a problem if you are relying only on phone-numbers as a factor, which Lyft was (so was Uber, in some markets). In reality, a lot of the time you verify the phone number and present a password challenge (aka ask for password) so it's not a huge problem. But then, you'd need to handle the case when Alice signs up in with the phone number 123, then changes their number to 456, and 6 months later Bob signs up with 123 because they are the new owners. Now, Alice has to provide a new number (with some Grace period) and Bob has to be eligible for all the promos / signup goodies that were previously tied to that 123 number again. Software is hard.