Todd Watts

An original engineering experiment

Make the decision visible.

A fictional telescope lending desk gives us a small problem with real design questions: what happens when a request is repeated, and what does a failed notification mean for a reservation?

Created for this portfolio with invented data and authored scenarios. This is an independent demonstration, not a reconstruction of a client or employer system.

Original engineering demonstration

One telescope.
One reservation.

A fictional community lending desk has one telescope left. Lose a reply or interrupt a notification, then inspect what changes and what must stay true.

Synthetic data · Local simulation

Community telescope library

The reply disappears. Is retrying safe?

  1. 01 / Caller

    Keep the request key

    loan-017

    Not requested

    0 request attempts
  2. 02 / Atomic store

    Reserve once

    No reservation

    One telescope available

    1 available · 0 reservations
  3. 03 / Notification worker

    Send independently

    No outbox intent

    Waiting for a commit

    0 intents · 0 send attempts

Step 0 of 8

Start with one available kit

Choose a scenario and advance one event at a time. Every state shown here comes from the same deterministic model.

0 / 8

The design decision

The same key and payload return the existing reservation. Reuse is checked before availability, so zero remaining stock does not turn a successful retry into a rejection.

Inspect the invariant and its limits

One key, one reservation. A retry must carry the same key and payload. Reusing the key with different inputs is rejected. The key receipt, conditional inventory update, reservation and outbox intent belong in one durable transaction.

One intent does not mean one notification. A provider can accept a message and lose its acknowledgement. Retrying can duplicate the message. Provider deduplication, backoff and retry limits would need their own implementation.

What this demonstrates. The model runs serialized commands in memory. It exercises replay and uncertain outcomes; it does not test database concurrency, crash recovery, retention policy or a real delivery provider.

An original demonstration with invented people, identifiers and events. It is not a reconstruction of client work. No API calls, accounts or saved visitor data.

More ways to inspect the thinking.

Explore the public MAINFRAME project, follow the animated system journey, or read the technical notes.

Discuss an engineering role or project