We need to start looking at obesity as a hunger disorder, and not as the result of an addiction, a lack of knowledge about nutrition, or a lack of self control. When an obese person regulates their eating and loses weight, the hunger often doesn't go away - and often increases. This is physical, not psychological hunger. When the obese person almost inevitably returns to eating to fullness, they regain weight. When a person takes GLP-1s, hunger is greatly reduced, and an obese person can eat less food while still achieving satiety without gaining weight. When they stop taking the GLP-1s, the hunger returns, and when they return to eating to fullness, they regain weight. Similarly, when a person takes stimulant weight loss medication, they can eat less food while experiencing less hunger, and thus lose weight. Similarly, when they go off of the stimulant (or develop a tolerance), the hunger returns and when they return to eating to fullness, they regain weight. In many obese people, the hunger is present even when they eat a nutritious meal at the appropriate number of calories to maintain their weight. Common advice is to say "this mix of macros or foods makes me satisfied!" and, well, that's great for you but not universal. People who naturally feel reasonably satisfied with an appropriate number of calories to maintain their weight still experience hunger, but not with the intensity or insatiability of that hunger that many obese people do. While it does occur with some who have severe eating disorders, most obese people do not overeat themselves into obesity by continuing to eat long after they're full. They eat until the hunger goes away. It's the hunger. Take away the hunger, and the weight goes down. Bring back the hunger and the weight goes up. It's simple, it's obvious, and few say it.
> If a user request is hitting that many things, in my view, that is a deeply broken architecture. Things can add up quickly. I wouldn't be surprised if some requests touch a lot of bases. Here's an example: a user wants to start renting a bike from your public bike sharing service, using the app on their phone. This could be an app developed by the bike sharing company itself, or a 3rd party app that bundles mobility options like ride sharing and public transport tickets in one place. You need to authentice the request and figure out which customer account is making the request. Is the account allowed to start a ride? They might be blocked. They might need to confirm the rules first. Is this ride part of a group ride, and is the customer allowed to start multiple rides at once? Let's also get a small deposit by putting a hold of a small sum on their credit card. Or are they a reliable customer? Then let's not bother them. Or is there a fraud risk? And do we need to trigger special code paths to work around known problems for payment authorization for cards issued by this bank? Everything good so far? Then let's start the ride. First, let's lock in the necessary data. Which rental pricing did the customer agree to? Is that actually available to this customer, this geographical zone, for this bike, at this time, or do we need to abort with an error? Otherwise, let's remember this, so we can calculate the correct rental fee at the end. We normally charge an unlock fee in addition to the per-minute price. Are we doing that in this case? If yes, does the customer have any free unlock credit that we need to consume or reserve now, so that the app can correctly show unlock costs if the user wants to start another group ride before this one ends? Ok, let's unlock the bike and turn on the electric motor. We need to make sure it's ready to be used and talk to the IoT box on the bike, taking into account the kind of bike, kind of box and software version. Maybe this is a multistep process, because the particular lock needs manual action by the customer. The IoT box might have to know that we're in a zone where we throttle the max speed more than usual. Now let's inform some downstream data aggregators that a ride started successfully. BI (business intelligence) will want to know, and the city might also require us to report this to them. The customer was referred by a friend, and this is their first ride, so now the friend gets his referral bonus in the form of app credit. Did we change an unrefundable unlock fee? We might want to invoice that already (for whatever reason; otherwise this will happen after the ride). Let's record the revenue, create the invoice data and the PDF, email it, and report this to the country's tax agency, because that's required in the country this ride is starting in. Or did things go wrong? Is the vehicle broken? Gotta mark it for service to swing by, and let's undo any payment holds. Or did the deposit fail, because the credit card is marked as stolen? Maybe block the customer and see if we have other recent payments using the same card fingerprint that we might want to proactively refund. That's just off the top of my head, there may be more for a real life case. Some of these may happen synchronously, others may hit a queue or event bus. The point is, they are all tied to a single request. So, depending on how you cut things, you might need several services that you can deploy and develop independently. - auth - core customer management, permissions, ToS agreement, - pricing, - geo zone definitions, - zone rules, - benefit programs, - payments and payment provider integration, - app credits, - fraud handling, - ride management, - vehicle management, - IoT integration, - invoicing, - emails, - BI integration, - city hall integration, - tax authority integration, - and an API gateway that fronts the app request. These do not have to be separate services, but they are separate enough to warrant it. They wouldn't be exactly micro either. Not every product will be this complicated, but it's also not that out there, I think.
↙ time adjusted for second-chance
I Program on the Subway (scd31.com)
 Top