Skip to content
C.W.K.
Stream
Lesson 01 of 04 · published

Pick the Clock Before You Pick the Stack

~12 min · cadence, architecture, low-trigger, complexity

Level 0Raw Ore
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Valuation is slow. Daily-close cadence is the native clock."

The decision that removes the most code

Before choosing a database, a framework, or a frontend, this product chose a clock: daily close. Everything downstream follows from it, and what follows is mostly absence.

No WebSocket layer. No reconnection with backoff. No heartbeat. No client-side subscription lifecycle. No partial-update reconciliation when a message arrives out of order. No decision about what happens to a half-rendered chart when the connection drops mid-session. No per-second state anywhere in the system, which means no question about how long to retain it or how to aggregate it later.

Count that up honestly. Choosing a slow clock deleted more code than any library choice could have added. And it did it at the only point in a project's life where deleting is free — before the code exists.

Why the domain permits it

This is not asceticism. It is a claim about the subject matter, and the claim is checkable: the quantities this app reports do not move on a fast clock.

A cyclically adjusted price-to-earnings ratio averages ten years of real earnings — it is not a number that means something different at 10:31 than at 10:30. The Buffett gauge's numerator comes from a quarterly statistical release. Index-level book values update on filings. The macro series behind the yield gap publish daily at best, and two of the three long-term government yield series this product reads are monthly.

Serving those at per-second resolution would not be more accurate. It would be more frequent, which is a different thing, and in this domain frequency is the ingredient that manufactures urgency out of data that has none.

Match the clock to the subject, not to the technology. The available update rate of your infrastructure is not a target. Ask how fast the underlying quantity actually changes, and sample at that rate. Sampling faster than your subject moves does not add information — it adds noise, and it adds the impression that something is happening.

The lineage: low-trigger by inheritance

The cadence also arrives from the family. The portfolio sibling's deepest invariant is emotional rather than numeric — it is built to be checked calmly, and it deliberately avoids the design vocabulary that makes financial software feel like a slot machine: big red numbers, live tickers, motion, escalating color.

A valuation engine that updated every second would inherit that vocabulary whether or not it wanted to, because motion is a rhetorical device. A number that changes while you are looking at it says something is happening, pay attention, and it says it before you have read a single label. The slow clock is a design choice about how the tool feels to a human standing in front of it — which, for a family financial tool, is not a secondary consideration.

Two independent reasons is what makes it permanent. If the cadence rested only on the emotional argument, a sufficiently keen contributor could argue it away. If it rested only on the provider constraint, it would evaporate the day the plan changed. It rests on both, from opposite directions — which is why the architecture doc can state it as an invariant rather than as a current preference.

Code

What choosing a slow clock deleted, before any of it was written·text
NOT IN THIS CODEBASE, BECAUSE OF ONE DECISION:

  websocket server + client
  reconnect / backoff / heartbeat
  subscription lifecycle (subscribe, resubscribe, unsubscribe)
  out-of-order message reconciliation
  partial-render recovery on mid-session disconnect
  per-second state: retention policy, aggregation, downsampling
  "is this tick stale?" logic on every consumer

IN THIS CODEBASE INSTEAD:

  one asyncio task
  one daily target time in one timezone
  one pass over every shipped gauge
  rows that carry their own data-date

# The second list is not a simpler version of the first.
# It is a different problem, chosen on purpose.

External links

Exercise

Take a system you work on and write down two rates: how often the underlying quantity actually changes, and how often your system samples or pushes it. If the second is much larger than the first, list the code that exists only to service the gap — transport, reconciliation, retention, staleness checks. That list is the price of a clock nobody chose deliberately.
Hint
The question that settles it is 'if I sampled ten times slower, what decision would a user make differently?' If the honest answer is none, the extra frequency is buying you complexity and a feeling, not information.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.