Engineering Philosophy: Salvatore Sanfilippo (antirez)

Key Takeaways

• His defining principle is to do less – a small, simple system you can hold in your head beats a large, feature-complete one. Salvatore Sanfilippo, known online as antirez, built Redis as a deliberately small store: single-threaded, in-memory, written in clean C, and ruthlessly resistant to features that would make it harder to understand. His essays return again and again to the same target – the complexity we add without counting its cost.¹⁵
• He created Redis in 2009, and it became one of the most-used databases in the world. Redis – the in-memory data-structure store – was first released on 26 February 2009, born out of his attempt to scale his Italian startup LLOOGG, a real-time web-log analyzer. He served as its sole maintainer and “Benevolent Dictator for Life” for eleven years.¹²
• Redis is single-threaded by design, and that is a feature. Rather than chase multi-core throughput, Redis runs commands one at a time on a single thread – which eliminates race conditions and lock overhead, keeps the model simple, and is fast enough because, as the Redis FAQ puts it, “it’s not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound.”⁷
• He treats code as something written by humans for other humans. In his “Writing system software” essays he argues that source “should be read other than being executed, since is written by humans for other humans,” and that the goal of readable code is “to lower the amount of effort and the number of details the reader should take into her or his head.”⁴

The Principle

“We are destroying software by no longer taking complexity into account when adding features or optimizing some dimension… We are destroying software with an absurd chain of dependencies, making everything bloated and fragile… We are destroying software by making systems that no longer scale down: simple things should be simple to accomplish, in any system.” – Salvatore Sanfilippo, “We are destroying software”⁵

Most engineering is addition. A feature is requested, so you add it. A dependency would save a week, so you pull it in. An optimization would help one user, so you bake it into the core. Each step seems locally reasonable – and the sum is a system no single person can hold in their head anymore. Sanfilippo’s instinct runs the other direction. The most dangerous line of code, in his philosophy, is the one you write without first asking whether you could avoid writing it at all. Do less. The question is never “what else can this do” but “what can this stop doing and still be worth using.”⁵

The clearest expression of the principle is Redis itself. It is single-threaded for command execution – a choice that, in 2009, looked almost perverse when the industry was racing to exploit multiple cores.¹⁷ But the reasoning is the principle made into architecture. A single thread executing one command at a time has no race conditions, no locks, no torn reads, no two-threads-mutating-the-same-key bugs. The mental model collapses to something a person can actually reason about: commands happen one after another, in order, atomically. And it gives up almost nothing in practice, because Redis is “either memory or network bound” long before CPU becomes the limit.⁷ The complexity of concurrency was a cost antirez refused to pay for a benefit most workloads never needed.

That refusal travels with two companions that make it affordable. The first is rich primitives: instead of forcing every problem through a single key-value model, Redis ships strings, hashes, lists, sets, sorted sets, and streams as native data structures, so the right tool is usually already in the box.¹ The second is code written for humans: he insists source is “written by humans for other humans,” and that good code lowers “the number of details the reader should take into her or his head.”⁴ Give people a few powerful primitives, do less than they ask, and write the whole thing so one person can still understand it. That is the principle, and Redis is the proof.

Context

Salvatore Sanfilippo was born on 7 March 1977 in Campobello di Licata, Sicily, Italy.¹ He grew up in a marginalized area of southern Sicily, near Gela, and moved to Palermo at seventeen to study architecture – a degree he never finished, shifting his focus to computer science and learning to program largely on his own.¹ The detail worth keeping is that he is self-taught, with no completed university CS degree; the craft came from doing the work, not from a credential. It is a recurring shape in this series – the deep practitioner whose authority rests on what they built, not what they were taught.

His first mark on the field was in security, not databases. He wrote hping, an open-source packet generator and analyzer for the TCP/IP protocol used for security testing.¹ More consequentially, in 1998 he published the idle scan – a stealth port-scan technique, originally called the “dumb scan,” that determines which services are open on a target “without leaving traces pointing back at oneself.”⁶ It works by exploiting a side channel: an idle third-party “zombie” host with predictable IP ID counters, which the attacker uses as a blind proxy to infer the target’s responses.⁶ The technique was clever enough to be incorporated into nmap and hping, where it remains.⁶ It is the same instinct that later defined Redis – find the elegant mechanism hiding underneath an apparently hard problem.

Redis itself came out of a practical scaling problem. In the late 2000s Sanfilippo was running LLOOGG, an Italian startup building a real-time web-log analyzer, and the existing databases could not keep up with the write rates he needed.¹ So in 2009 he built his own in-memory store, and released Redis on 26 February 2009.¹² It spread fast, and the sponsorships tracked its rise: VMware hired him in March 2010, Pivotal Software (a VMware spin-off) took over sponsorship in May 2013, and Redis Ltd. assumed it in June 2015.¹ He served as the project’s sole maintainer and BDFL for eleven years, then stepped down on 30 June 2020, succeeded by Yossi Gottlieb and Oran Agra.¹ In December 2024 he returned to Redis as an evangelist and active contributor – the rare creator who left at the top and came back.¹

The Work

Redis and its data structures: powerful primitives, not a blank key-value store

Start with what makes Redis different, because it is the principle made into product. Most key-value stores give you exactly that – a key, an opaque blob of a value, and the burden of building everything else yourself. Redis instead ships rich data structures as primitives: strings, hashes, lists, sets, sorted sets, and – since Redis 5.0 – streams.¹ Each is a native, server-side type with its own commands, so the data structure you would have hand-rolled in application code already lives in the database, operated on atomically by that single thread.¹⁷ The payoff is that hard application features collapse into a handful of commands, because the right primitive is already there.

The sharpest example is the sorted set (ZSET). It is a collection of unique members, each carrying a floating-point score, and Redis keeps the members “taken in order” – ordering is a property of the data structure itself, not something computed on request.³ Under the hood it is a dual-ported structure, a skip list paired with a hash table, which gives O(log(N)) inserts and zero extra work to read results back in sorted order.³ You add or update a member’s score with ZADD, and read a member’s rank with ZRANK (lowest first) or ZREVRANK (highest first).³ The canonical use case is the one every game needs and every traditional database dreads: the leaderboard. As the Redis docs put it, “you can use sorted sets to easily maintain ordered lists of the highest scores in a massive online game.”³

Why it matters as engineering: a leaderboard in a relational database is a genuine pain. Every score change means an UPDATE, and every “what rank is this player” query means an ORDER BY across the whole table or a maintained index – work that grows with the number of players and contends under load. In Redis the ranking is intrinsic to the structure. ZADD costs O(log(N)) and ZREVRANK costs O(log(N)), and the set is already sorted, so reading the top ten is trivial.³ The feature did not get easier because Redis is faster at the same work – it got easier because Sanfilippo chose to ship a primitive whose shape is the solution. That is “do less” from the user’s side: the database did the hard part once, so a thousand applications never have to.

Single-threaded and in-memory: simplicity as the design center

Redis makes two choices that look like limitations and are in fact the source of its strength. It is in-memory – the working data set lives in RAM, with durability layered on through snapshots and an append-only file – and it is single-threaded for command execution, processing requests one at a time on a single core.¹⁷ Both choices are “do less” in disguise.

The single-thread decision is the more counterintuitive one, and the reasoning is worth following. A multi-threaded store has to coordinate concurrent access to shared data – locks, atomics, lock-free structures, memory barriers – and that machinery is where a frightening share of database bugs and unpredictable latency live. By running one command at a time, Redis makes every command atomic by construction: there is no interleaving to reason about, no lock to forget, no race to debug.⁷ The official FAQ is blunt about why this costs so little: “It’s not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound,” and single-threading “avoids race conditions and CPU-heavy context switching associated with threads.”⁷ The throughput the design gives up is throughput most workloads were never going to use; the simplicity it buys is paid back on every line of code and every 3 a.m. debugging session.

This is the same temperament as his single-threaded refusal to add complexity in the essays. He frames the failure mode precisely: “We are destroying software by no longer taking complexity into account when adding features or optimizing some dimension.”⁵ Multi-threading is exactly the kind of optimization – of one dimension, raw CPU throughput – that would have multiplied the system’s complexity for a benefit most users never needed. Saying no to it kept Redis a system one person could hold in their head, which is the property that let one person maintain it for eleven years.¹

The craft: C written for humans, and the case for comments

The third body of work is not a feature but a stance on how code should be written. Sanfilippo writes Redis in C – a language with no guardrails, where the programmer is responsible for every byte – and he treats the readability of that C as a first-order concern, not an afterthought. His essay “Writing system software: code comments” is an unusually direct argument that source exists primarily as communication. Code, he writes, “should be read other than being executed, since is written by humans for other humans.”⁴ The executable behavior is only half the job; the other half is the next person – often a future you – who has to understand it.

From that premise he derives a working theory of comments and clarity. The goal of readable code, he argues, is “to lower the amount of effort and the number of details the reader should take into her or his head while reading some code.”⁴ A comment earns its place when it removes a detail the reader would otherwise have to reconstruct – the why behind a non-obvious choice, the invariant a function assumes, the reason a fast path exists. This is craft in the deepest sense: not cleverness, but care for the human who comes after. It pairs exactly with the “do less” principle, because the smaller and simpler the system, the fewer details there are to carry, and the more honest the code can be about the ones that remain.

The same conviction drives his broader critique of where software is heading. He warns against “an absurd chain of dependencies, making everything bloated and fragile,” and against systems “that no longer scale down: simple things should be simple to accomplish, in any system.”⁵ Redis is his counter-argument made executable – a system with few dependencies, a small comprehensible core, and a design where the simple thing stays simple. The craft is not decoration on top of the engineering; it is the engineering.

The Method

Read across Redis, the idle scan, the essays on comments and complexity, and the single thread, and the same commitments recur. Sanfilippo’s method is less a slogan than a set of standing habits.

Do less – the most dangerous code is the code you did not need to write. The defining habit is subtraction: before adding a feature, a dependency, or an optimization, ask whether the system can survive without it. He names the failure mode directly – complexity added “without taking it into account.”⁵ The lesson transfers far past databases: every line you do not write is a line that cannot break, cannot confuse the next reader, and cannot have to be maintained for a decade. It is minimum worthy product at the level of a system’s core – ship the smallest thing that is genuinely worth using, and defend its smallness against the steady pressure to grow.

Ship powerful primitives, not pre-built policy. Redis hands you sorted sets, streams, and hashes – general structures from which you build leaderboards, queues, and rate limiters – rather than a bespoke feature for each.³ The standing habit is to find the underlying mechanism that solves a whole class of problems and ship that, so the database does the hard part once. It is the same bet Roberto Ierusalimschy made with Lua’s tables and metatables – give people sharp, general levers and let them build the rest – and the kinship is not accidental, since Redis embeds Lua to do exactly that.

Choose simplicity even when it costs throughput. The single-threaded design is the clearest case: Redis declines multi-core parallelism for command execution because the simplicity – no races, no locks, atomic-by-construction – is worth more than the cores, and the CPU was rarely the bottleneck anyway.⁷ The discipline is to know which dimension actually constrains you and refuse to pay complexity to optimize a dimension that does not. This is the evidence gate applied to performance: do not add concurrency because it sounds fast; measure where the bottleneck really is, and most of the time it is not the CPU.

Write code for the human who reads it next. Source “is written by humans for other humans,” and the job of a comment is to lower the details the reader must carry.⁴ The habit is to treat readability and explanatory comments as part of correctness, not a nicety to add later – because a system no one can understand is a system no one can safely change. It is the same human-centered craft Donald Knuth pushed to its limit with literate programming: the program is a piece of writing aimed at a person.

Hold the whole system in one head. Redis stayed maintainable by one person for eleven years because it was kept small enough to be comprehensible by one person.¹ The standing commitment is to treat comprehensibility-by-an-individual as a hard design constraint – if the system grows past what one mind can hold, you have lost the thing that made it trustworthy. It is the solo-craft instinct Linus Torvalds and the Unix tradition share: a tool with a clear, bounded job, owned and understood deeply rather than sprawled and delegated.

Influence Chain

Who Shaped Him

The Unix and C tradition. Sanfilippo writes system software in C, by hand, with care for every byte – the lineage of Thompson and Ritchie, where small tools do one thing well and the language gives you full control and full responsibility.⁴ His insistence that code is written for humans to read is the readable-C ethic of that tradition carried into the database era. (Formative influence)

The security and networking hacker culture of the late 1990s. Before Redis there was hping and the idle scan – low-level packet work that demanded a precise mental model of TCP/IP and a hacker’s eye for the elegant side channel hiding in a protocol.¹⁶ That habit of finding the clever mechanism underneath an apparently hard problem is the same one that produced Redis’s data structures. (Direct influence)

The constraint of a real product. Redis was not designed in the abstract; it was forced into being by LLOOGG’s need to ingest web logs faster than existing databases allowed.¹ The pressure of a concrete, urgent problem – not a desire to build a database for its own sake – is what shaped Redis toward doing exactly what was needed and little more. (Formative influence)

Who He Shaped

A generation of application architectures. Redis became the default for caching, session storage, rate limiting, real-time leaderboards, and pub/sub – so ubiquitous that “put Redis in front of it” is reflexive engineering advice, and its data structures reshaped how developers think about what a database can offer.¹³

The “rich primitives” school of data stores. By proving that a store could ship sorted sets and streams as first-class types rather than opaque values, Redis pushed the whole field toward richer server-side data structures and away from the blank key-value model. (Field-defining influence)

The case for small, opinionated, single-author systems. Redis stands as working proof that a deliberately small system, maintained by one person with taste, can become global infrastructure – an argument that echoes through every “do less,” minimal-dependency, comprehensible-core design since.⁵

The Throughline

Sanfilippo sits with this series’ minimalists – the builders who believe the highest form of engineering is subtraction. Rich Hickey drew the line in “Simple Made Easy”: simple means un-braided, one fold, one concern, and complexity is the interleaving we add for convenience and pay for forever. Redis is that argument compiled to C – a single thread so there is one concern, not the braid of concurrency; rich primitives so the data structure is not entangled with application code.⁵⁷ And Roberto Ierusalimschy built Lua tiny enough for one person to comprehend, shipping mechanisms instead of policy – the same bet Redis makes with its primitives, which is why Redis embeds Lua to let users script atomically against them. Both descend from the Unix economy of Thompson and Ritchie: a tool with one clear job, written in readable C, small enough to understand whole. Where Hickey says keep it simple, not merely easy and Ierusalimschy says ship the lever, not the rule, Sanfilippo says: do less – give people powerful primitives, run them one at a time so the model stays in your head, and write every line for the human who reads it next. (Series bridge)

What I Take From This

The lesson I keep from antirez is that the code I do not write is the most valuable code in the system. My instinct, like most builders’, is to solve a problem by adding – a feature, a dependency, a thread, a clever optimization. Redis is an eleven-year argument that the addition is usually the mistake. The single-threaded design is the one I think about most: he declined the thing everyone said you had to do – exploit the cores – because the complexity it brought was not worth a benefit his workload never needed.⁷ When I build something now, the question I borrow is “what can I refuse to add and still ship something worth using?” Because every line I skip is a line that cannot break, cannot confuse, and cannot demand maintenance for the next decade. Doing less is harder than doing more, and far more durable.

The second lesson is that code is writing, and the reader is a person. It is easy to treat source as instructions for a machine and stop the moment the tests pass. Sanfilippo treats it as communication – “written by humans for other humans” – and judges it by how few details the next reader has to carry in their head.⁴ That reframed comments for me: not noise to be minimized, not an apology for unclear code, but the place where I hand the next person the why they could never reconstruct from the what. The discipline of writing for the reader is inseparable from the discipline of doing less, because the smaller and simpler the system, the more honest its code can be – and the more likely that one person, years from now, can still hold the whole thing in their head. That is quality is the only variable read as restraint: the right small thing, written for humans and defended against bloat, becomes infrastructure the world can stand on.

FAQ

What is Redis?

Redis is an open-source, in-memory data-structure store, created by Salvatore Sanfilippo (antirez) and first released on 26 February 2009.¹² Rather than storing opaque values like a plain key-value cache, it offers rich native data structures – strings, hashes, lists, sets, sorted sets, and streams – operated on atomically by the server.¹ Because the working data set lives in RAM (with durability via snapshots and an append-only file), it is extremely fast, which is why it became one of the most widely used databases in the world for caching, session storage, queues, rate limiting, real-time leaderboards, and pub/sub.¹⁷

Who is antirez?

antirez is the online handle of Salvatore Sanfilippo, an Italian (Sicilian) self-taught programmer born on 7 March 1977 in Campobello di Licata, Sicily.¹ He is best known as the creator of Redis (2009), which he maintained as sole developer and BDFL for eleven years before stepping down on 30 June 2020 and returning to the project in December 2024.¹ Before Redis he did notable security work – writing the hping packet tool and, in 1998, inventing the idle scan, a stealth port-scanning technique later incorporated into nmap.¹⁶ He writes thoughtfully about simplicity, code comments, and the craft of system software on his blog at antirez.com.⁴⁵

Why is Redis single-threaded?

Redis executes commands one at a time on a single thread because the simplicity is worth more than multi-core throughput for its workloads. A single thread makes every command atomic by construction – there are no race conditions, no locks, and no torn reads to reason about.⁷ And it costs little in practice: as the Redis FAQ explains, “it’s not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound,” and single-threading “avoids race conditions and CPU-heavy context switching associated with threads.”⁷ It is Sanfilippo’s “do less” principle as architecture – decline the complexity that optimizes a dimension (CPU) that was rarely the constraint.⁵⁷

What is a Redis sorted set?

A Redis sorted set (ZSET) is a collection of unique string members, each associated with a floating-point score, with members kept automatically in score order.³ You set or update a member’s score with the ZADD command and read its position with ZRANK (lowest score first) or ZREVRANK (highest first); the structure stays sorted at all times, so reading ranked results requires no extra sorting work.³ Internally it uses a skip list paired with a hash table, giving O(log(N)) inserts and O(log(N)) rank lookups.³ The classic use is a real-time leaderboard – a feature that is painful in a relational database but collapses to a couple of commands in Redis because the right primitive already exists.³

Sources