SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsthinking-antirez

thinking-antirez

Coding & development

View repository

Updated 10-15 08:05

About this skill

antirez (Salvatore Sanfilippo) Thinking Framework

"Redis was born from a very practical need. I was trying to solve a specific problem, and I couldn't find a tool that did exactly what I wanted. So I built one." — antirez

Introduction

Salvatore Sanfilippo, known online as antirez, is the creator of Redis. Redis is one of the most widely used in-memory databases in the world, powering real-time features for countless internet products. But antirez's value lies not only in having written a great piece of software, but also in the fact that he embodies an extremely rareengineering aesthetics—using the least code, the simplest design, and the most direct implementation to solve the most essential problems.

antirez is not a computer scientist (he was originally a security researcher), and he did not use complex algorithms and theories to build Redis. His philosophy is:good code should be like a good story—clear, concise, and without fluff. He proved that one person can single-handedly maintain a global-scale infrastructure project for more than a decade, relying not on superhuman ability, but on an extreme pursuit of simplicity.

Core Thinking Models (5)

1. Radical Simplicity

antirez's first principle:If it can be simple, do not make it complex. It is not "as simple as possible," it is "radically simple"。

How minimalism is embodied in Redis's design:

  • Five core data structures(String, List, Hash, Set, Sorted Set) cover 90% of use cases. Not 50, not 10, but 5.
  • Single-threaded model —When the whole world was saying "multithreading is the future," antirez insisted on single-threading. Why? Because single-threading requires no locks, has no race conditions, keeps the code simple, and makes behavior predictable. The performance bottleneck is not the CPU but memory and network I/O, and single-threading is fast enough.
  • Commands as APIs —Each Redis command does one thing and does it well. There are no "Swiss Army knife"-style super commands.

Decision rules of minimalism:

面对一个设计选择：

1. 有没有更简单的方案？（如果有，用更简单的）
2. 这个复杂度是"必要的"还是"我觉得很酷的"？
3. 如果去掉这个功能，核心价值还在吗？（如果在，考虑去掉）
4. 新来的人能在多长时间内理解这个设计？（越长越需要简化）

antirez's "subtraction" principle: Every time you want to add a feature, first ask, "What if we don't add it?" If the answer is not "users will be unable to complete the core task," then don't add it.

2. Pragmatism Over Purity

antirez does not pursue theoretical perfection; he pursuespractical usability。

Several key pragmatic decisions:

  1. It is an in-memory database but does not guarantee perfect durability —Redis persists asynchronously by default (AOF/RDB), so it may lose the last few seconds of data. antirez's view: in most scenarios, losing a few seconds of data is acceptable, and what you get in return is a performance improvement of more than 10x. Perfect durability is left to traditional databases.

  2. ** eventual consistency rather than strong consistency** — Redis Cluster may lose writes during a network partition. antirez believes that for caching and real-time scenarios, this is completely OK.

  3. API design follows "user intuition" rather than "theoretical consistency" —The naming and behavior of some Redis commands are not fully consistent, but antirez cares more about "what users find natural" than "what is academically elegant."

Pragmatism decision matrix:

              理论完美
                │
  不做（保持   │    做，但要
  简单但略有   │    简化接口
  不完美）     │
                │
 ──────────────┼──────────────
                │
  不做（理由   │    做，简单
  不充分）     │    直接实现
                │
              实际有用

→ 左上：理论上完美但不实用 → 不做
→ 右上：理论完美且实用 → 做但要简化
→ 左下：不完美也不实用 → 不做
→ 右下：不完美但实用 → 做了再说

3. Readability as First Priority

antirez's code is widely recognized as "textbook-level" readable. His principles:

Concrete practices for readability:

  1. Use the most straightforward implementation, not the most "clever" one

    • antirez doesn't show off. If it can be solved with if-else, don't "optimize" with bitwise operations
    • "Clever code" is the enemy of maintenance—six months later you won't understand your own "cleverness"

  2. Comments explain "why", not "what"

    • The code itself should explain "what"
    • Comments supplement "why it's done this way"—the design rationale and trade-offs behind it

  3. Functions should be short and sharp

    • Each function does one thing
    • If a function exceeds 50 lines, it most likely should be split

  4. Naming should be straightforward, not abbreviated

    • createStringObject() instead of crtStrObj()
    • Code is read far more often than it is written

antirez's code aesthetics:

// 好代码：直白、清晰、一眼看懂
if (listLength(server.ready_keys) == 0) return;

// 差代码：聪明但不透明
if (!*server.ready_keys) return;  // 利用C的指针特性"优化"

4. Constraints as Features

Another counterintuitive idea from antirez:Actively impose constraints, and the constraints become features。

Constraints as features in Redis:

  1. Single-threaded → no need for locks → simple code → predictable behavior → easy debugging
  2. Memory constraints → force you to think about data lifecycle → natural eviction strategies (LRU/LFU) → better cache design
  3. Data structure size limit (512MB) → prevent a single key from dragging down the entire instance → force reasonable data modeling
  4. Command atomicity → each command either fully executes or doesn't execute → naturally avoids race conditions

Design principles of constraints as features:

当你在设计一个系统时：

1. 列出所有"必须支持的"和"最好能支持的"
2. 把"最好能支持的"砍掉一半
3. 在剩下的必须项中，设置合理的上限
4. 每个限制都要有清晰的技术理由
5. 文档化这些限制，让用户知道边界在哪里

限制不是缺陷。限制是选择。

5. Incremental Complexity

antirez doesn't pursue a one-shot design, but ratherstarts from the simplest version and gradually adds complexity based on real needs。

Redis's evolution demonstrates this principle:

v1.0 (2009): 基本的5种数据结构 + 持久化
  ↓ 用户需要复制
v2.0 (2010): 主从复制
  ↓ 用户需要更多数据结构
v2.6 (2012): Bitmaps, HyperLogLog
  ↓ 用户需要高可用
v2.8 (2013): Sentinel（自动故障转移）
  ↓ 用户需要水平扩展
v3.0 (2015): Redis Cluster
  ↓ 用户需要模块化扩展
v4.0 (2017): Modules 系统

Each step of added complexity is driven by clear user demand, not by "I think users might need this."

Rules of incremental complexity:

  1. The first version only does the core functionality — the 80/20 rule: 20% of features cover 80% of needs
  2. Wait for real user feedback — rather than guessing what users need
  3. Add only one layer of complexity at a time — don't add too much at once
  4. When adding complexity, review the existing design — does the new feature make existing features unnecessary?

Decision framework

Feature addition decision

有人建议增加一个新功能：
│
├─ 它解决了一个真实的问题吗？
│   ├─ 否 → 不加
│   └─ 是 → 能用现有功能组合解决吗？
│       ├─ 能 → 文档化组合方案，不加新功能
│       └─ 不能 → 加了之后核心复杂度增加多少？
│           ├─ 很少 → 加，但要简化接口
│           └─ 很多 → 找更简单的替代方案
│               ├─ 找到了 → 用替代方案
│               └─ 没找到 → 再考虑加

Code quality checklist

Code review in the antirez style:

## 代码审查 — antirez 风格

### 简洁性
- [ ] 有没有更简单的实现方式？
- [ ] 有没有不必要的抽象层？
- [ ] 有没有过度工程化的部分？

### 可读性
- [ ] 6个月后的我能看懂吗？
- [ ] 命名是否直白？
- [ ] 注释解释了"为什么"而不是"做什么"？
- [ ] 函数是否足够短？

### 复杂度
- [ ] 新增了多少行代码？（越少越好）
- [ ] 引入了多少新的依赖？（越少越好）
- [ ] 增加了多少认知负担？（越少越好）

### 实用性
- [ ] 这解决了真实的问题吗？
- [ ] 有没有更简单的替代方案？
- [ ] 去掉这个功能，用户会怎样？

### 限制
- [ ] 有没有主动设置合理的边界？
- [ ] 这些限制有技术理由吗？
- [ ] 文档化了吗？

Classic quotes (8 items, with sources)

  1. "Redis was born from a very practical need. I was trying to solve a specific problem, and I couldn't find a tool that did exactly what I wanted. So I built one." — antirez blog, "Redis, two years later" (2011)

  2. "Simplicity is the most important thing in software design. Complex software breaks in complex ways." — antirez blog, "Writing software is mostly about rewriting" (2018)

  3. "I try to write code that is boring to read. If it's exciting, it means it's too clever." — antirez's talk at RedisConf 2017

  4. "The best code is the code you don't write." — repeatedly mentioned by antirez in multiple blog posts about Redis's design philosophy

  5. "Every line of code is a liability. Every feature is a commitment. Think twice before adding either." — antirez blog, "Redis use cases" (2012)

  6. "Single-threaded means I don't have to think about locks. Not thinking about locks means I can think about the problem." — a core idea expressed many times by antirez in various technical interviews

  7. "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." — quoting C.A.R. Hoare, which antirez repeatedly followed when designing Redis

  8. "When in doubt, leave it out. If it's really needed, someone will ask for it." — the minimalist principle expressed by antirez in Hacker News comments

Practical Templates (3)

Template 1: Minimalist Design Audit

# 极简设计审计 — [项目/模块名称]

## 1. 功能审计
| 功能 | 使用频率 | 是否核心 | 能否用其他功能替代 | 建议保留/删除 |
|------|----------|----------|-------------------|--------------|
| 功能A | 每天/每周/很少 | 是/否 | 是/否 |           |
| 功能B | 每天/每周/很少 | 是/否 | 是/否 |           |
| ...  |          |          |                   |              |

## 2. 复杂度热点
| 模块 | 行数 | 圈复杂度 | 最近修改频率 | 是否可以简化 |
|------|------|----------|-------------|-------------|
|      |      |          |             |             |

## 3. 依赖审计
- 外部依赖数量：___
- 内部模块间耦合度：高/中/低
- 可以移除的依赖：___

## 4. 简化计划
| 要简化的事项 | 当前状态 | 目标状态 | 预计收益 |
|-------------|----------|----------|----------|
|             |          |          |          |

## 5. 新增功能预审
- 最近6个月新增了几个功能？___
- 有几个被广泛使用？___
- 有几个可以去掉而不影响用户？___

Template 2: antirez-style Code Review

# antirez 风格代码审查

## 被审查代码
- 文件：___
- 变更摘要：___

## 第一轮：简洁性检查
- [ ] 有没有重复的逻辑？（→ 提取函数）
- [ ] 有没有过度抽象？（→ 扁平化）
- [ ] 有没有"以防万一"的代码？（→ 删掉YAGNI）
- [ ] 总行数是否必要？（→ 能否减少30%？）

## 第二轮：可读性检查
- [ ] 命名是否自解释？
- [ ] 函数是否只做一件事？
- [ ] 控制流是否线性？（避免深度嵌套）
- [ ] 是否有"聪明"但难懂的代码？（→ 改成直白的版本）

## 第三轮：实用主义检查
- [ ] 这个变更是解决真实问题还是"未来可能需要"？
- [ ] 有没有更简单的实现？
- [ ] 增加了多少复杂度？值得吗？

## 评分
- 简洁性：___/5（5=极简）
- 可读性：___/5（5=教科书级别）
- 实用性：___/5（5=解决真问题）
- **总分：___/15**（12+优秀，9-11良好，<9需要重写）

Template 3: Progressive Architecture Roadmap

# 渐进式架构路线图 — [项目名称]

## v0.1 — 最小可用版本（MVP）
- 核心功能（只做绝对必要的）：___
- 预计时间：___
- 预期用户数：___（内部/测试）
- 成功标准：___

## v0.2 — 基于反馈的第一轮迭代
- 前提：收集到足够的真实用户反馈
- 计划增加的功能（基于反馈）：
  1. ___
  2. ___
- 计划简化的部分：
  1. ___

## v0.3 — 稳定化
- 修复v0.2的问题
- 优化性能瓶颈
- 补充文档

## v1.0 — 对外发布
- 前提：至少经过3轮真实用户使用
- 功能冻结
- API稳定性承诺

## 原则
1. 每个版本只增加1-2个新功能
2. 每个功能必须有真实用户需求驱动
3. 每个版本都要比上个版本更简单（或至少不更复杂）
4. 定期删除不需要的功能

Application Scenarios

1. Software Architecture Design

  • Examine your system with antirez's minimalism: Are there any unnecessary intermediate layers?
  • Is the responsibility of each module clear? (Redis's 5 data structures = 5 modules with clear responsibilities)
  • Constraints are features: proactively set reasonable boundaries

2. API/Interface Design

  • Redis's imperative API is the most concise reference for interface design
  • Each API does one thing, and does it well
  • Don't design "universal interfaces"; design "specialized interfaces"

3. Technology Selection

  • When choosing tools, prefer tools that "do one thing but do it extremely well" over tools that "can do everything but are mediocre at everything"
  • Unix philosophy + antirez philosophy: combine small tools to solve big problems

4. Personal Productivity

  • Minimalism applies to workflows: the fewer tools, the better; the simpler the process, the better
  • "Single-threaded" work mode: do only one thing at a time, avoid context switching
  • Constraints are features: set limits for yourself (e.g., do only 3 important things each day)

5. Team Engineering Culture

  • Use antirez's standards in code review: concise, readable, practical
  • Encourage "subtraction": deleting code deserves more praise than adding code
  • New features must be driven by real needs; "might be needed in the future" is not accepted

Anti-patterns

❌ Minimalism = laziness

→ antirez's minimalism is the result of deep thought. He spends more time thinking about "how to simplify" than most people spend on "how to implement." Minimalism is the result of design, not cutting corners.

❌ Over-simplifying to the point of unusability

→ Simplification has boundaries. If simplification makes it impossible for users to complete core tasks, it is over-simplification. Redis's 5 data structures cover 90% of scenarios—but that remaining 10% also needs to be served (which is why the module system was later added).

❌ The single-threaded panacea theory

→ Redis is single-threaded because its bottleneck is IO, not CPU. If your system is CPU-intensive, single-threading is a disaster. antirez's lesson is "choose the architecture that suits you," not "single-threading is always right."

❌ Opposing all abstraction

→ antirez opposes "unnecessary abstraction," not all abstraction. Redis itself makes extensive use of abstraction (the object system, event loop, networking layer). The key is that every abstraction layer has a clear reason to exist.

❌ Ignoring testing

→ The conciseness of antirez's code does not mean he doesn't test. Redis has an extremely strict test suite. Conciseness is meant to make testing easier—the simpler the code, the easier it is to write tests.

❌ One-person heroism

→ antirez maintained Redis alone for many years, but he also said this was unsustainable, and eventually Redis was taken over by the community. His "solo project" model applies to the special case of a genius-level developer + extremely high self-discipline, not to ordinary teams.

Summary

The core of antirez's thinking framework isradical simplicity + pragmatism + gradual evolutionHe proved that the best software is not the one with the most features, but the one that is simplest—because only simple software can be understood, trusted, and maintained over the long term.

Apply antirez's thinking to your work:

  1. Every time you want to add something, first ask “what can be removed” — subtraction takes priority over addition
  2. Make code so straightforward it's boring — if the code is “interesting,” it may be too complex
  3. Set limits, embrace limits — limits are a design tool, not a defect
  4. Evolve gradually, don't try to get it all at once — the first version only does the core, and the rest waits for feedback

"I would say that the most important quality for a programmer is not intelligence or knowledge, but the ability to resist the temptation to over-engineer." — antirez