Designing the Ending: Why a Good Server Should Know How to Close

Pocket edition. This is a shorter version of a longer article; you can read the full edition when you have more time.

Nobody opens a server thinking about how they'll close it. And yet they all end: the small ones and the giants. The only question left open isn't whether a server will close, but how —and that part almost nobody designs.

It matters more than it seems. Daniel Kahneman described the peak-end rule: we remember an experience above all by its most intense moment and by how it ended, not by its average. A server that gave you two good years and then disappears one night without warning doesn't leave you the memory of the two years: it leaves you the memory of the closed door. The ending, fairly or not, colours everything before it.

Closing well isn't a sentimental gesture, it's respect for the time people gave you. It means giving plenty of notice, saying a real goodbye, letting people take away what they built, being grateful. The opposite —the address that one day no longer connects— is the most common way and the poorest.

Almost nobody does it, and not out of malice: closing well forces you to admit it's over, and the pride of whoever built something resists that. But the lesson holds for almost everything done with people —a project, a job, a relationship—: it isn't remembered by its average, it's remembered by how it ended.

I haven't had to close anything yet, so this is intention with a principle behind it, not proof. But a server isn't measured only by how it welcomes you. Also by whether, when the day comes, it knows how to say goodbye.