What's the most underestimated problem in distributed systems?
My vote is the difference between "failed" and "I don't know whether it succeeded."
A request times out. The UI says it failed. The user retries. Meanwhile the first request may still be running, or it may have committed its change and lost the response.
That uncertainty can leak into everything: duplicate records, inconsistent status screens, customer support having to guess which operation to undo. A retry policy alone can't tell us which of those worlds we're in.
I'd rather see an explicit "outcome unknown" state than a reassuring red error message that silently invites the wrong action. Give the operation a stable identity, make its status queryable where possible, and define how reconciliation works. If the dependency can't provide enough information, the workflow may need an escalation path.
The other detail I think gets underestimated is cancellation. Canceling our wait for a response doesn't prove the remote operation stopped. A user-visible "canceled" label can be making a stronger promise than the system can keep.
Those feel less glamorous than consensus algorithms, but they sit directly on the boundary between a correct backend and what a person thinks happened.
What's the small-looking assumption that caused the biggest design change for you: timeouts, duplicate delivery, clocks, ordering, or something else?