The Telegraph Clerk's Unread Message: A Precedent for Idempotency

In the spring of 1873, a routine inquiry crackled down the wire from London to the small station at Penzance, Cornwall. It was a simple request for a status update on a previous message. The clerk in Penzance, having already sent his reply hours before, faced a now-familiar dilemma. The original answer was lost, or at least its confirmation was. He could re-send the substantive reply, but doing so could be misinterpreted as a new, urgent development. Or, he could repeat just the acknowledgment, a mere “message received,” which felt empty. His solution, dutifully recorded in the telegraph company’s logs, was a curious hybrid. He re-sent the original message, but prefixed it with a single, crucial symbol: a repetition of the message’s own serial number, followed by the word “DUPLICATE.”

This small, procedural act from a Victorian clerk is an early, concrete blueprint for a concept we now formalize in our digital systems: idempotency. In our world, an idempotent operation is one that can be applied multiple times without changing the result beyond the initial application. A patient health check endpoint that returns the same 200 OK on the thousandth call as it did on the first is idempotent. A status update that won’t double-process if a network hiccup triggers a retry is idempotent. The clerk understood, intuitively, that the reliability of the system depended not just on the message getting through, but on the intent of the message being understood correctly, regardless of how many times the mechanism was triggered.

We often think of uptime monitoring as a matter of receiving a signal. A ping returns, a check passes, a green light illuminates. But the true challenge, as the telegraph network discovered, lies in the ambiguity of repeated signals. A flapping service can trigger a storm of alerts; a retry logic gone awry can bombard an API. Without idempotency, our observability tools themselves can become sources of noise and error, mistaking the echo for a new voice.

The Penzance clerk’s “DUPLICATE” prefix was a form of metadata attached to the payload, a header that instructed the receiver on how to process the content. It said, “This is not new information; integrate it under the previous transaction ID.” It turned a potential state-altering confusion into a safe, repeatable operation. In building reliable services, we must design our health checks, our state updates, and our recovery mechanisms with this same clerk’s foresight. Is our “system restored” alert idempotent, or does each retry spawn a new incident ticket? Does our deployment script handle being run twice?

The pursuit of uptime, then, is not merely about preventing silence. It is about ensuring that when the system speaks—especially when it must repeat itself—its language is unambiguous. It is about building a network where a repeated message clarifies, rather than corrupts, the state of the world. The next time you design an endpoint or a monitoring probe, spare a thought for that clerk, listening to the repeater-click of his sounder, carefully annotating his re-transmission to preserve the sanity of the system. The most reliable services are built not just to send signals, but to send them wisely, again and again.

Notes & further reading

A few pages I came back to while writing this: