Start here

Most posts here explain something complex with one diagram and concise text. I've organised them by borrowing the layers of Clean Architecturethe closer to the core, the more stable and portable (concepts); the further out, the more concrete and replaceable (tools). Dependencies point inward, and so does learning: get the inner concepts solid first, then learn the tools that will eventually be swapped out.

This is the complete map. Posts translated into English are listed by their English title; the rest are marked 中文 and open the Chinese original — 103 of 181 posts are in English so far.

Infrastructure concrete · replaceable Application transformation · architecture Domain core concepts SQL · FoDE · DDIA dbt · Medallion Redis · Kafka · Spark · Airflow · K8s Dependencies: outer → inner Outer layers depend on inner ones, never the reverse. Outer (tools) get replaced; inner (concepts) stay stable. Learning order: core concepts first, then tools SRE + LGTM observability reliability cuts across every layer War stories — tested in practice real systems tie every layer together Tech Leader — beyond the technology
Core · Domain

Core concepts: the most stable, most portable layer

This is the layer you keep using through several jobs — the query language, the mental map of data engineering, the principles behind data-intensive systems. Tools get replaced; these don't. Get this solid first, then move outward.

Application & architecture

Transformation and architecture: organising concepts into systems

The layer between concepts and tools — how raw data is refined into usable models, how transformation and layering are arranged, and a few architectural ideas I think are most worth understanding.

Infrastructure

Infrastructure: the concrete tools that make the concepts real

The outermost, most concrete, most replaceable layer. Each of these tools turns the concepts above into something that runs — but they are the means, and the core concepts are the end. When looking at a tool, keep asking which concept it implements.

📚 Configuration management · Ansible for DevOps — Reading Notes · 4 posts (0 in English)

  1. 1 Ansible 是什麼?從告別雪花伺服器講起 中文
  2. 2 Ansible ad-hoc:一行指令,管一群機器 中文
  3. 3 第一份 Playbook:把 shell 腳本翻譯成宣告式 中文
  4. 4 Playbook 進階:變數、條件,與重新定義成功 中文

📚 Distributed coordination · standalone

  1. 1 Apache ZooKeeper:分散式系統的協調核心 中文
Cross-cutting

Reliability and observability: across every layer

This layer cuts across everything — data has to be correct, services have to stay up, changes have to be safe, and all of that presupposes being able to see. SRE covers the concepts and culture of reliability (the why); the Grafana LGTM stack covers turning it into real dashboards, alerts and SLOs (the how). It's also where I spend the most effort now, as the DE team's EM and its SRE at once.

Practice · War Stories

War stories: rebuilding real systems

Every concept above is tested here against systems I actually built (and actually got wrong). The first battlefield: a live-commerce platform — users ordering by comment, inventory that must never oversell, payments and fulfillment in one chain; each chapter first tells how it was done then, and how I'd design it if starting over.

Beyond tech

People and growth: tech leadership

The other line beyond technology — the lessons of leading people, and, just as important from 2026 on, the lessons of leading AI.

Looking for a specific topic? Use the search at the top right, or browse by tag.