Assuming their internal projects are built similar to OSS, I ask you to try playing with them yourself and see if you come to the same opinion. There's better w

Assuming their internal projects are built similar to OSS, I ask you to try playing with them yourself and see if you come to the same opinion. There's better ways to critique an arch than just measuring outages. Netflix has built an amazing system for messing with their servers to try find failure points. And they have a bunch of cleanup jobs that run to fix consistency errors. This is just what I picked up from a past obsession with their architecture. Then I worked on a few projects built that way, and realized it was a horrible nightmare. By having a global immediately consistent datastore you can push all these concerns back to the database, and your codebase ends up far smaller. The failure modes tend to explode in complexity when you're doing rpc across services with different datastoress because you have to deal with distributed transactions yourself. Every single call needs to be able to unwind itself across all services. If you have a call that fans out to 10 other service calls, you need to be able to unwind any of them in any order. It quickly becomes untenable