partial failure
On a single computer, things tend to fail all-or-nothing: either the whole machine is running, or it has crashed and everything stops together. A distributed system is different, and stranger. Imagine a relay race where one runner trips and falls, but the others keep sprinting because they cannot see what happened behind them. In a distributed system, one node can crash, or one network cable can be cut, while every other node keeps running, completely unaware. This is partial failure: some parts of the system are alive and some are dead at the very same moment.
What makes partial failure genuinely hard is not that nodes fail — it is that you usually cannot tell failure apart from slowness. Suppose you send a request to another machine and hear nothing back. Did the machine crash? Did your request get lost? Did it arrive, get processed, and then the reply got lost? Is the machine just busy and the answer is still coming? From where you stand, all of these look identical: silence. Because messages take time and can be dropped, and because there is no shared clock to agree on what happened when, a timeout is only a guess, never a proof, that the other side is dead.
Why it matters: partial failure is the single fact that shapes nearly everything else in distributed computing. It is why we need timeouts and retries (which then create the at-least-once versus at-most-once problem), why we need replication so the system survives losing a node, why we need consensus protocols to agree despite some participants vanishing, and why the CAP theorem forces a hard choice when the network splits. The honest takeaway: you cannot make partial failure go away — you can only design so the system keeps making sense when it happens.
Your bank app sends "transfer 100 dollars" to the server and the screen freezes, then times out. You genuinely do not know: did the transfer happen and only the confirmation get lost, or did the whole request never arrive? Press the button again and you might pay twice. This ambiguity is partial failure in your daily life.
Silence does not tell you whether the work was done. That ambiguity is the heart of the problem.
A common beginner mistake is to treat a network call like a local function call that simply either returns or throws. It does not: it can also silently do the work and then fail to tell you. Handling that third outcome is most of the work.