Skip to content
Published on

What Distributed Systems Taught Me About Relationships

🇰🇷KO🇺🇸EN🇯🇵JA
필사 모드
Authors

Introduction — There Is Always a Network Between Two Nodes

The reasons distributed systems are hard are well known. The network is unreliable. Messages get lost or arrive late. You cannot even be sure the other node is still alive. And most fundamentally, you can never directly observe the internal state of the node on the other side. You infer everything about it from the messages it chooses to send you.

Read that sentence again and it is also a description of what it is like to be close to another human being. Two people are two independently running systems, and between them lies a channel you cannot fully trust. A tone of voice, a facial expression, the speed of a reply, a silence. We spend our lives estimating the unobservable state of another person's heart from these lossy, ambiguous signals.

After enough years of building distributed systems, the solutions inside them started to sound, oddly, like relationship advice. A system that assumes a perfect network will always eventually fall over. A relationship that assumes a perfect partner does the same. The answer in both worlds is identical. Not perfection, but resilience, explicit acknowledgment, and a little grace. This post walks through nine places where the two overlap.

Retries with Backoff — Don't Spam the Texts

When a request fails, you must not simply fire it again immediately. If the server on the other end fell over from overload, and every failed client retries at once, you get a retry storm that finishes off the server entirely. So well-built systems use exponential backoff. The first retry waits one second, the next two, the next four. As failures pile up, you widen the gap to give the other side room to recover. You add a bit of random jitter on top, so that everyone does not stampede back at the exact same instant.

That is precisely the posture you want when a text goes unanswered. Seeing it read with no reply and immediately firing off "?", "you up?", and "what are you doing" in quick succession is a retry storm. The other person might be in a meeting, exhausted, or simply gathering their thoughts. What that moment needs is not harder knocking but a wider interval. Send once, then wait. Then wait longer.

When there is no reply, the answer is not more often but less often. Backoff is not indifference. It is room for the other person to recover.

The jitter lesson applies too. Do not reach out at the exact same time in the exact same tone every day. Predictable pressure is its own kind of weight.

Timeouts — Decide in Advance How Long You'll Wait

A request with no timeout is one of the most dangerous things in a system. A thread waiting forever for a response holds its resources and hangs indefinitely, and when enough of those pile up, the whole system slowly strangles. So mature systems put an upper bound on every external call. "If there is no answer within this window, treat it as a failure and move on." Waiting must always have an end.

In relationships too, waiting without a bound is a hung system. Waiting indefinitely for "someday they'll open up" or "someday they'll change" is the same as a thread that holds its resources while processing nothing. Meanwhile every other request in your life gets pushed back in the queue and quietly starves.

Setting a timeout is not about rushing the other person. It is about being honest with yourself. Deciding in advance how long you will wait and what you need to see. If that window passes with no signal, that is not a reason to resent them. It is a quiet permission to transition to your next state.

A wait with no defined end is not devotion. It is a hang.

Heartbeats — The Small "How Was Your Day" Ping

Nodes in a distributed system exchange small periodic signals to know that the other is still alive. These are heartbeats. Not heavy payloads, just a light "I am here" ping. When several heartbeats fail to arrive in a row, a node concludes its peer is dead and begins to react. Confidence that a connection is alive comes not from any grand event but from the steadiness of these small signals.

Relationships are held together the same way. It is not the big occasions or anniversaries that keep a bond alive. It is the low-information but steady pings: "Did you eat?", "How was your day?", "Get to work okay?" When those small signals start to drop, the connection is, in truth, already quietly weakening.

What matters is frequency, not size. A heartbeat is supposed to be lightweight. Every exchange does not need to be a deep conversation. It only needs to be regular. And if the other person's heartbeats have not arrived for a few days, what is needed before frustration is the sensitivity to notice. A system reads silence as a sign of failure. So do people.

Consistency Models — Are We On the Same Page Right Now

In distributed systems, strong consistency means every node always sees the same value. Whoever reads, whenever they read, is guaranteed the latest state. It is expensive: coordination takes time and eats into availability. Eventual consistency, by contrast, tolerates brief disagreement. Different nodes may hold different values right now, but absent new updates, they will all converge on the same value in time. Good design does not force strong consistency on all data. It picks where strong consistency is genuinely required.

Relationships are the same. Try to keep everything perfectly synchronized at every moment and you will both burn out. Things like "Are we actually together?" and "Are we exclusive?" are items that require strong consistency. Leave those to eventual consistency and you risk discovering, far too late, that the two of you have been living in different relationships. That kind of thing must be agreed explicitly and synchronized immediately.

Meanwhile, "What should we watch this weekend?" or "Which restaurant?" is fine on eventual consistency. Even if you do not agree perfectly this instant, a few rounds of conversation and it converges on its own. Demand strong consistency down to this level and the relationship fills up with meetings.

Some things must hold the same value right now. Some only need to agree eventually. Knowing which is which is what maturity looks like.

Backpressure — Only Send What They Can Handle

When a fast producer dumps data onto a slow consumer, the consumer's buffer overflows and the system eventually collapses. So a well-designed pipeline has backpressure. The consumer signals back to the producer, "I can only take this much right now," and the producer slows its flow to match. The consumer sets the pace, and the sender adapts to it.

People have processing capacity too. Pour your worries, your plans, your hurt, and your demands onto someone in the middle of a brutal week, all at once, and their buffer overflows. However right your words are, pushed in at a moment they cannot receive, they are dropped. Not for lack of love, but because the queue is full.

The heart of backpressure is that it hands the consumer control of the rate. In a relationship this shows up as asking first: "Do you have the space to talk about this right now?" And when they signal "today is a lot for me," reading that not as rejection but as flow control. A good partner observes the other's capacity and adjusts their own send rate. It is not giving less love. It is giving it at a rhythm the other person can actually receive.

Graceful Degradation — On a Bad Day, Keep the Core Running

A large service does not take everything down because one part broke. If the recommendation engine dies, it turns off recommendations and keeps the core, checkout and login, running. This is graceful degradation. Rather than losing everything, you deliberately shed the less important features to protect the most important one.

People do not get to live only good days either. There are days when you are sick, drained, or falling apart. Demanding full operation from a relationship on those days is unrealistic. The bonus features, the clever jokes, the meticulous thoughtfulness, the long conversations, may switch off for a while. As long as the core service, the signal that says "I am on your side," stays alive, the relationship survives the day.

This applies to yourself as much as to the other person. On your own hard days, instead of straining to be the perfect partner, just keep the core running. On the other person's hard days, what is needed is the grace not to treat a dip in their usual attentiveness as an outage. Knowing that the frontend is just a little rough right now, while the backend is still very much alive.

The goal on a day you are falling apart is not full operation. It is keeping the core service alive.

Idempotency — Saying Sorry Twice Is Not Twice as Sorry

Idempotency is the property that applying the same operation multiple times leaves the same result as applying it once. Attach an idempotency key to a payment request and, even if a network error causes the same request to arrive twice, the customer is charged only once. It is the first application that changes state. The retransmissions after it change nothing.

An apology is exactly this. A real apology, once, delivered properly, changes state. But repeat that same apology ten times and does the relationship recover tenfold? It does not. If one sincere apology has already moved the state, the repetitions after it change nothing further. Worse, repeating "but I already apologized so much" quietly converts the apology from something for the other person's recovery into a request to relieve your own guilt. That is no longer an idempotent operation. It is a retransmission that accumulates side effects.

There is a mirror-image trap. The other person has already accepted it and the state has changed, but you never registered that fact and keep retransmitting the same apology. A system should trust the peer's ACK and stop retransmitting. In a relationship, that trust is stopping when they say "it's okay, I heard you."

Saying sorry twice is not twice as sorry. One real apology changes the state. Everything after it is for you.

The Two Generals Problem — Did That Message Actually Get Through

The Two Generals' Problem is one of the most famous impossibility results in distributed computing. Two generals, separated by a valley, must agree on a time to attack while communicating only through messengers who cross enemy territory. The catch is that any message can be lost along the way. General A sends "attack at dawn." General B sends an acknowledgment. But A does not know whether that acknowledgment arrived. So B wants confirmation that A received the acknowledgment. This confirmation of a confirmation goes on forever, and over an unreliable channel perfect agreement is provably impossible.

The quietest misunderstandings in a relationship are born right here. You are certain you conveyed how you felt. But whether that message reached the other person, and whether, having reached them, it was understood as you intended, you cannot be one hundred percent sure. "Of course they know" is an unverified assumption. A feeling you never expressed is an unsent packet, and even a feeling you did send can suffer the loss called misunderstanding.

If perfect agreement is theoretically impossible, what is the practical answer? The same as the system's answer. Exchange ACKs explicitly, and for the things that matter, run one more round of confirmation. Asking back, "I understood it this way, is that right?" Reflecting the other person's words back in your own language to check. You can never reach perfect certainty, but every extra round of explicit acknowledgment reliably lowers the probability of misunderstanding.

Assuming they understood is a message sent with no delivery receipt. The more it matters, the more you run one extra round of confirmation.

Trust as a Cache with a TTL — It Expires If You Don't Refresh It

A cache stores a result so you do not repeat an expensive lookup every time. But it usually comes with a TTL (Time To Live), an expiry. Once that time passes, the cached value is stale and must be checked against the source again. The reason for a TTL is simple: the world changes, and an old cache eventually drifts out of sync with reality.

Trust is exactly this cache. We do not re-verify the other person from scratch at every moment. On the basis of accumulated experience, we cache the value "this person is trustworthy," and thanks to that cache we skip the expensive operation of doubting them each time. That is why trust makes a relationship fast and light. But this cache has a TTL. Trust left untouched for a long time, with no refresh, quietly goes stale. So trust has to be continually refreshed through steady interaction.

And betrayal, from this angle, is cache invalidation. A single event that breaks faith invalidates the whole cached trust value at once. After invalidation, you are back in the age of expensive lookups. You have to re-verify against the source every time, and rebuilding the cache takes far longer than it took to build the first time. The cache called trust is slow to build, invalidated in an instant, and the most expensive of all to rebuild.

Trust is a cached value, not a permanently stored truth. It expires if you do not refresh it, and betrayal invalidates the whole cache at once.

Wrapping Up — There Is No Perfect Network

The nine ideas above look like separate stories, but they share a single root. The reason distributed systems are hard and the reason relationships are hard are exactly the same. You cannot directly observe the other's internal state, the channel between you is unreliable, and the other is an independent entity who does not move on your command. On top of these conditions, the two of you have to cooperate.

On top of these conditions, any design that aims for perfection is guaranteed to fail. A protocol that believes messages are never lost. A relationship that believes the other always understands perfectly. Both collapse at the first fault. So good systems and good relationships aim for the same thing. Not to eliminate failure, but to survive it. That is resilience, explicit acknowledgment, and the grace to accept the other's imperfection as a normal state rather than an outage.

Backing off instead of spamming texts. Setting a timeout instead of waiting forever. Sending small heartbeats steadily. Agreeing strongly on what matters. Letting things flow at the rate the other can take. Keeping only the core alive on hard days. Apologizing once, properly. Running one more round of confirmation on the important words. And diligently refreshing the cache called trust. This is good engineering, and it is, probably, good love.

References

Discuss on Twitter • View on GitHub