# 用課堂筆記建立課程 wiki

這是三份講義的虛構練習：追蹤座位預訂從資料庫寫入到快取失效，再用 10 對 9 的反例檢查流程。

## 任務

只根據講義，回答座位預訂應如何安排資料庫寫入與快取失效。包含快取過期的反例，並列出講義沒有指定的每個數值。每個主張都用 [[filename]] 引用。

## 預期推理

資料庫是權威來源；先寫入資料庫，再讓快取失效。失效失敗時，下一次座位讀取必須查資料庫。資料庫有 9 個座位而快取仍顯示 10 個，證明只看快取做預訂決定不安全；租期與重試次數仍未知。

## 完整來源資料包

### Lecture 01 — Database is the source of truth — lecture-01-consistency.md

```markdown
# Lecture 01 — Database is the source of truth

In this course example, the course_seats table in the database is authoritative for available seats.

A cache may accelerate reads and carries an expires_at value, but a cached value is not a booking decision. After a successful database reservation commit, the cache may still hold the old value until it is invalidated.
```

### Lecture 02 — Invalidation follows a write — lecture-02-cache-invalidation.md

```markdown
# Lecture 02 — Invalidation follows a write

For a seat reservation, commit the database transaction first. Then invalidate the concrete key course-seats:course-42.

If invalidation fails, mark the key stale and force the next seat read from the database; retry invalidation. Never write the cache first and assume that the database commit will succeed.
```

### Lecture 03 — Counterexample and unknowns — lecture-03-counterexample.md

```markdown
# Lecture 03 — Counterexample and unknowns

At 09:00, the database says 10 seats and the cache says 10. At 09:01, a reservation commits in the database, leaving 9 seats. The invalidation worker is down, so the cache remains at 10.

A cache-only availability check now overstates the seats and is unsafe for a reservation decision.

These notes do not specify a cache lease duration or an automatic invalidation retry count. Leave both values unknown.
```

## Reference answer: write to the database first, distrust stale cache state

The database is authoritative. Commit it before invalidating the cache; after a failed invalidation, the next seat read must use the database. The 10-versus-9 counterexample proves that a cache-only reservation decision is unsafe, while lease duration and retry count remain unspecified.

# Course-seat consistency — reference

## Answer

The database is the source of truth for available seats. A cache can accelerate a read, but its value cannot by itself authorize a reservation. [[lecture-01-consistency.md]]

The safe order is to commit the reservation in the database first and invalidate the course-seats cache key afterward. The workflow must never write the cache first and assume that the database commit will succeed. [[lecture-02-cache-invalidation.md]]

If invalidation fails, mark the key stale, make the next seat read come from the database, and retry invalidation. [[lecture-02-cache-invalidation.md]]

## Counterexample

The notes give a concrete stale-read case: the database moves from 10 to 9 seats after a reservation while the cache remains at 10 because its worker is down. A cache-only availability check therefore overstates availability and is unsafe for a reservation decision. [[lecture-03-counterexample.md]]

The lease duration and automatic invalidation retry count are not defined by these notes. Keep both as unknowns instead of inventing settings. [[lecture-03-counterexample.md]]

## 變更後來源

### lecture-02-cache-invalidation.md

```markdown
# Lecture 02 — Invalidation follows a write, revision 2

For a seat reservation, commit the database transaction first. Then invalidate the concrete key course-seats:course-42.

If invalidation fails, mark the key stale and route every seat decision to the database until a successful invalidation clears the stale state. Never write the cache first and assume that the database commit will succeed. The notes still do not specify an automatic retry count.
```

## 變更預期

The initial reference's phrase next seat read from the database becomes too narrow. After the revised lecture, every seat decision must bypass the cache until a successful invalidation clears the stale state. Database-first ordering, the 10-versus-9 counterexample, and the unknown lease duration remain unchanged; no retry count may be invented.

## 審查邊界

核對 10 對 9、先寫資料庫再讓快取失效，以及失效失敗後的處理；租期和重試次數保持未知。

## 比較

幾份講義可以手動複核。當修訂後的教材、反例與尚未決定的實作選擇需要在後續學習中保持連結時，來源連結的課程 wiki 才有幫助。

## 閱讀本地化頁面

https://wenlan.app/zh-TW/learn/build-course-wiki-from-lecture-notes