The Three Clocks Framework: Designing Real-Time Systems

All week I’ve been writing about clarity, architecture, and the foundations that help teams move fast without breaking trust. Today’s idea brings those themes together.

Every real-time platform runs on three clocks.

Most teams only design for one.

This is why systems feel fast but fail under pressure, or feel consistent but never scale.

Real-time behavior is not about milliseconds alone. It is about coordinating three very different timelines. Here are the three that matter.

1. User Time

This is the world users believe they live in. Actions feel instant. Feedback must match what they expect, not what the back end is doing.

If a user thinks something happened, the system needs to reflect that belief in a predictable way. Latency here becomes a trust problem, not a technical one. Nielsen Norman Group’s research on response times is still the definitive read on what “instant” means to a human. Spoiler: 100 milliseconds is the cliff.

2. System Time

Services do not live in the user’s world.

They process events at their own pace. They retry when needed. They apply back-pressure, handle load spikes, and resolve ordering and concurrency issues. Martin Fowler’s writing on event-driven architecture patterns is a good primer on how services actually coordinate under load.

System time is where the real work happens.

3. Business Time

This is where correctness lives.

Ledgers, settlements, compliance, reporting, and audit trails care about the exact order and truth of events, even if finalization takes longer. The Google SRE book chapter on data integrity treats this as a first-class engineering concern, not an afterthought.

A payment may feel instantaneous to a user, but may not be fully settled until later. Business time governs rules and truth, not clicks.

A Bid at Auction Close

Imagine an online auction. The clock is winding down, ten seconds remaining. Someone taps “Bid $500” on their phone.

That single action, one tap, is happening across all three clocks at once. Whether it succeeds or fails depends on whether the three timelines stay coordinated.

User time. The user needs immediate feedback. If the tap doesn’t show “Your bid: $500” within a hundred milliseconds, they’ll tap again. And again. Every duplicate tap is a duplicate bid, or worse, a race condition that the system now has to untangle. The interface has to acknowledge the intent instantly, even before the bid is validated. A spinner isn’t optional here. It’s the difference between one bid and five.

System time. The bid enters a queue. It has to be validated (does the user have available funds? is this bid higher than the current leader? is the user still authorized to bid?). It has to be ordered relative to every other bid arriving in the same millisecond. It has to be persisted with a durable timestamp and a monotonically increasing sequence number. The service handling this may be under peak load: thousands of similar bids landing in the final seconds. It doesn’t get to be slow.

Business time. The auction has a hard close: exactly 3:00:00 PM. A bid stamped 2:59:59.999 is valid. A bid stamped 3:00:00.001 is not, and that boundary has legal weight. Winner determination isn’t just “highest bid,” it’s “highest bid received before the close, with tie-breaking by arrival timestamp.” Settlement, invoice, and contract obligations follow from that determination.

Now imagine the seams:

• The bid feels placed at 2:59:59.850 (user time). But the system doesn’t fully persist it until 3:00:00.100 (system time), because a downstream write was retrying. In business time, that bid is late. The user won the auction in their belief. The auction house says otherwise. Who’s right?

• The system processes bids correctly, but the auction’s official close time is bound to an NTP-synchronized clock, while the bid-arrival timestamp is bound to the application server’s clock. They drift by 300 milliseconds under load. On a normal Tuesday nobody notices. On a hotly contested auction close, the drift decides who wins.

• The user’s device network path introduces 800 ms of latency. Their bid arrives, correctly, at 3:00:00.500. It’s rejected, correctly, per business time. But from user time it feels like the system stole the auction from them. Support gets called. The auction house’s reputation gets shaped, one review at a time.

The point isn’t that any of these three seams is a bug. Each service is doing exactly what it was designed to do. The failure lives in the assumption that a single tap on a single phone is a single event, when it’s actually a distributed event whose meaning depends on three different clocks agreeing about when it happened.

This is why real-time systems are hard. Not because the individual pieces are hard. Because the pieces have to agree about time, and time is the thing they most reliably disagree about.

Where Most Failures Come From

Most failures in real-time systems happen because a team optimizes for one clock at the expense of the others.

Optimize only for user time, and your ledger gets corrupted. Optimize only for business time, and your users abandon the flow. Optimize only for system time, and neither users nor auditors trust what they see.

What Good Looks Like

When you design with all three clocks in mind:

• UIs become predictable
• Event workflows become resilient
• Ledgers stay trustworthy
• Failures become localized
• Scale becomes a property of architecture, not hardware

Real-time platforms succeed when they respect the idea that time is not single-threaded. The system must reconcile three timelines into one coherent experience.

Once you see the three clocks, you start designing differently.

---

This framework pairs naturally with what I’ve written about starting with good and Lister’s Law more broadly. Real-time systems succeed when these three timelines stay aligned.