# Build a course wiki from lecture notes

A fictional three-note exercise: trace a seat reservation from database write to cache invalidation, then test the 10-versus-9 stale-cache counterexample.

## Task

Using only the lecture notes, answer how a seat reservation should order the database write and cache invalidation. Include the stale-cache counterexample and list every value the notes leave unknown. Cite each claim with [[filename]].

## Expected reasoning

The database is authoritative; write it first, then invalidate the cache. If invalidation fails, the next seat read must use the database. The cache showing 10 while the database has 9 makes a cache-only reservation decision unsafe, and lease duration plus retry count stay unknown.

## Complete source packet

### 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]]

## Changed source

### 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.
```

## Expected change

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.

## Review boundary

Check 10 versus 9, the write-before-invalidate order, and the path after failed invalidation; keep lease duration and retry count unknown.

## Comparison

A few notes can be reviewed by hand. A source-linked course wiki helps when revised lecture material, counterexamples, and unresolved implementation choices must remain connected for later study.

## Read the localized page

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