Pretending to Delete

Algorithms, a semester of SQL, and the slow realization that in real systems we mostly only pretend to delete.

A look back — long before any of the tools we argue about now.

This is the last of my memories of studying computer science — the database course, and the algorithms course that led up to it, closing out what I learned in school in the 1990s.

Algorithms

After data structures in my sophomore year, algorithms arrived as the course for learning to program “properly.” The book was thick enough to be intimidating on its own. I worked hard at the front of it, held my breath through graphs, and somewhere around greedy methods and NP-hard and NP-complete I simply found it difficult. At first I took it for no more than a set of slightly cleverer ways to solve a given problem, but I kept turning back to it — in grad school, and later in working life — and for one reason or another it kept earning its keep. Ten years after graduating, when I set out to interview at Google, it was the book I gritted my teeth and opened again; what’s left of it now is fragments.

INSERT / SELECT / DELETE

The database course came at the very end of my undergraduate years. There was a book, though it never quite felt like a textbook, and what I remember is SQL, all semester long. The sharpest thing that stayed with me — I can’t reconstruct the exact tone — was a grad student who came in as our lab assistant and told us, “For the rest of your lives you’ll need nothing else; just know SELECT.” More than twenty-five years on, working with SQL that is still very much in use, I found myself thinking of him again.

There was the minor argument over whether SQL counts as a programming language, but it remains one of the most used, and by now whatever tool you pick probably supports it out of the box. Work on the backend and you’ll get a fuller look; otherwise, the prophecy about SELECT has more or less come true. In the AI era, perhaps we’ll be learning how to coax GPT into writing good SQL — a chain of person to GPT to SQL to database to machine that feels already half here.

is_deleted

In data structures and algorithms, the thing that took the most time was implementing delete — keeping the state from breaking, returning memory properly, holding everything together so that the far more frequent searches stayed fast. It was the part that gave me the worst headaches whenever I tried to build a system. In the database course, though, the most time went to a different question: how to make deletion recoverable. Real services carried the same worry — what happens when something deleted still needs to come back, and then what becomes of the backup — and the usual answer was to not actually delete anything, and only act as though you had.

It was a little deflating, honestly, how often adding an is_deleted field was all it took for a feature to work. Later I found the same idea already everywhere — page memory in the kernel, the way NAND flash behaves — less like rubbing something out with an eraser than throwing white paint over it. When a departed user signs up again, do you reuse what was there? And under certain laws, did you truly delete it? That one small question — “is it deleted?” — turns out to hold a great deal of room for misunderstanding.

P.S. On a single service it never shows, but once you meet scale, some things reveal enormous read performance the moment they’re frozen read-only — and watching the same concerns come around again as domains and generations change, maybe there’s something to the old line about none of it going to waste.

Part of 90s Computer Science Stories — first-person notes on growing up with computers and studying CS in Korea in the 1980s and ’90s. See the full series →

Adapted from my Korean essay on Brunch: brunch.co.kr/@chaesang/57