Posted about 17 hours after the incident.
In short, a valid customer configuration change triggered a bug. One thing I don't see in this writeup is a commitment to ensure that customer configurations cannot break the whole system. Cloudflare does seem to make this promise with their zero trust architecture,
https://www.cloudflare.com/learning/security/glossary/what-i...
The generic topic your looking for is probably something like "customer isolation" ("service isolation" might also be relevant, but is used also in the context of "tenant isolation" which isn't really what you want). See this thread: https://news.ycombinator.com/item?id=25237836 for some talk about how AWS does "cellularization" which is a form of workload/service isolation/partitioning.
In general I don't think there's much discussion of this issue on the wider web.
Fastly's downtime seems to be caused by an automatically generated config that got deployed in production as a result of change requested by a legitimate customer.
This happened to CF in its early days and I really doubt that ZT had anything to do with the fact that they do not have this kind of problem anymore. It's probably some sanity checks before they deploy updated lua scripts to their fleet of nginx's if anything.
Isn't that too early for pay mortem? I didn't experience it myself, but I think it happened at most few hours ago.