# [[vn-2025-06-26 Remediations before ghosting and the role of doubt]] Date: 2025-06-26 ## Main points - Discusses ghosting and circuit breaker pattern in relation to traffic management. - Advises against immediately terminating communication with overloaded components. - Suggests adapting to traffic changes using load balancers and rerouting. - Recommends implementing a priority-based fallback system and rate limiting. - Emphasizes trying various remediations before making drastic changes. - Defines rollback as a drastic option when other solutions fail or testing doesn't reproduce defect. - Encourages questioning and doubt as part of remediation akin to ghosting. - Relates the process to site reliability engineering, nihilism, and Nishitani KG's view on doubt. - Asserts that questioning is necessary before final drastic actions like ghosting. ## Transcript Okay, this is still on the topic of ghosting and some sort of circuit breaker pattern, because the first one only lasted for a minute, so I'm not sure why that was. But what I was saying was there is a point at which, let's say there's a component that's receiving a lot of traffic. You're not going to want to shut off all communication with the problem component right away. You're going to want to try to adapt to that change in load, so you probably try to use a load balancer and try to reroute the traffic, you know, have other nodes that maybe can shoulder part of the load, part of the traffic. Then you might implement some sort of priority-based fallback system. So you could do that. You could do some rate limiting. So it's all these interventions that you might have to do before, and you should try those first. Um, all these remediations before you do anything else, anything more drastic. So what would be drastic? A drastic thing would be a rollback. I think sometimes this is the first thing that people do, actually. But like sometimes when you just can't figure it out, and or maybe testing doesn't reproduce the defect and yet it clearly is occurring, or you just don't have the time to do the remediation right now, then probably the safest thing to do would be to implement a rollback, which means falling back to the previous version that worked. The point is that you don't start with that. The point is that you should do the other stuff first. What else would be the equivalent of like ghosting? It could mean re-architecting the whole thing. Maybe this is something that I can relate not just to site reliability engineering but also to nihilism and Nishitani KG's version of nihilism and about how doubt is a form of care. Those remediations that you do before the actual ghosting happens, that could be in the form of questions. So it's encouraging the doubt and trying to see like, well, something happened, so where could it have gone wrong? Something had to have gone wrong, so let's try and find it. So even these things that we thought were previously working, maybe they still are. Maybe it's time to question those assumptions. And the goal here is not to just question endlessly or to just prove that something fails. The goal is ultimately to try to fix it, and in that way, doubt is a form of care. Doubt is necessary; that questioning period, the remediation, is necessary before the final ghosting. Even the ghosting itself may eventually be necessary, but at least you've done all the other stuff beforehand. ![[FcFnQ2Mu.mp3]] ## Related Notes - [[vn-2025-06-26 Connecting circuit breakers and ghosts in engineering]] - [[vn-2025-06-26 Understanding System 1 and System 2 thinking]]