In my last job, the service mesh was responsible to do retries. It was a startup and the system was changing every day.
After a while, we suspect that some services were not reliable enough and retries were hiding this fact. Turning off retries exposed that in fact, quality went down.
In the end, we put retries in just some services.
I never tested neither retry budget nor deadline propagation. I will suggest this in the future.
I think somewhat different than the article in some ways.
The first example is why `UPDATE CASCADE` was implemented. So it's possible to use natural keys as identity without the fear of children table. At least in most databases it works.
The drawback of enumeration is real, so if you expose this key you'll need some authentication/ authorization mecanism.
Another good thing in natural keys is that you can eliminate part of the joins. You don't have to join the father table because the key in child table is known.
I think the biggest challenge is how to map logins to people. It's very common to interpret both as the same, but they are not.
Well, I'm sorry for your experience. Now in a manager chair I have both experiences, setting bad OKRs and good OKRs. The performance and communication improvements when you get it right are astonishing. Unfortunately, I'm not consistent yet.
But when you find a manager/ place where people get it right, you'll love it.