A design review says only "we will keep it in the shared tier" - what do you ask to pin down which role is meant?
answer
- name the role, not the component
- time lost, or a fact lost
- who owns the rebuild being possible
- "both" means two populations, label them
basics
~20 sAsk what is lost if an entry vanishes: time or a fact. Then ask whether anything else can produce it again, whether correctness needs exactly one holder, and whether anyone offline must receive it later. Those answers name the role.
solid answer
~50 s"In the shared tier" names a component, not a role, and the four roles lead to different designs. I would ask four things. **If this entry vanished between two requests, what is lost - time, or a fact?** That separates a derived copy from the sole home for ephemeral state. **Is there something that can produce the value again, and who keeps it able to?** That turns assumed derivability into a stated precondition. **Does correctness depend on exactly one caller getting a particular outcome for one key?** That is a coordination point. **Must anyone who was not connected receive this later?** If yes, a transient transport is the wrong component. If the answer to the first question is "both", the design has two entry populations sharing one deployment, and they should be labelled and sized separately.
go deeper
Remember that "we will keep it in the shared tier" names a component, not a purpose. The first thing to ask is what is lost if an entry disappears between two requests: time, or a fact nobody else holds.
Be able to run the identifying questions in order and say what each answer changes. The one that does most work is whether anything else can produce the value again, because it separates a derived copy from state with no other home.
Show that you ask who owns keeping the rebuild possible, rather than accepting that it is possible. In review, insist that a design holding facts with no other holder says so explicitly, because that sentence is what sets restart and ceiling posture.
Make the role a required field of a design, not a conversation. Where one deployment carries several populations, the strictest sets the settings for all of them; decide whether that is an accepted cost or a reason to separate them.
## Why "keep it in the shared tier" is not yet a design The sentence names a **component** - a separate in-memory store the application reaches across a hop. It does not name the **role** that component is playing, and the four roles lead to different answers on every question the review still has to settle: what must survive a restart, what the entry's deadline means, how much memory the tier needs, and what the calling service does when the tier is empty or unreachable. Two reviewers can nod at the same sentence while picturing designs whose failure behaviour is opposite. The identifying questions below are cheap to ask and they close that gap before it reaches production. ## The questions that identify the role 1. **If this entry vanished between two requests, what is lost - time, or a fact?** The single most separating question. "Time" means a **derived copy**: something authoritative still holds the value. "A fact" means the tier is the **sole home for ephemeral state**. 2. **What can produce this value again, and who is responsible for keeping it able to?** Derivability is a precondition that someone has to own, not a property you may assume. If nobody can name the **system of record**, the honest answer to question 1 was "a fact". 3. **Does correctness depend on exactly one caller getting a particular outcome for one key?** If yes, the design wants a **coordination point** - one shared place several processes consult so that a thing taken by one is visible to the others - and being slow is not its interesting failure. 4. **Must anyone who was not connected at that moment receive this later, acknowledge it, or replay it?** If yes, a **transient transport** is the wrong component and the subject has left this tier entirely: a retained log is a different thing with different owners. 5. **Does the entry's deadline mean something to the business, or is it only a freshness bound?** A deadline that is merely "how stale may this copy get" can be shortened for capacity. A deadline that defines how long something is held or valid cannot be, because shortening it changes what the system promises. 6. **Who writes it - is the truth created here, or does a copy land here?** Writes that originate in the tier are the strongest sign that role two, three or four is in play, whatever the design document calls it. ## What each answer changes | Answer you get | Role named | What the review must now decide | |---|---|---| | "We would just read it again, slower" | Derived copy | How stale a copy may be, and how large the hot subset is | | "We would not know it happened" | Sole home for ephemeral state | What is kept across a restart, and what the ceiling does | | "Two workers might both run it" | Coordination point | How long a holder's deadline is, and what a failover costs | | "Only whoever is listening gets it" | Transient transport | Whether losing it for the disconnected is acceptable | ## When the answer is "both" It frequently is, and that is not a problem by itself. It means the deployment carries **two entry populations with different roles**, and the review's job is to label them rather than average them. The consequence is concrete: the strictest population sets the posture for the whole deployment. A tier holding both derived copies and facts nothing else has cannot be configured to reclaim freely under memory pressure, because the same behaviour that is harmless for one population is silent loss for the other. ## Two answers to distrust - **"Of course we can rebuild it."** Ask what the rebuild reads from, and whether the values in the tier were ever written there directly. Aggregates computed once, counters incremented in place, and anything a process wrote and nothing else did are the usual entries that turn out to have no source. - **"We will add a deadline later."** Which deadline, and meaning what? In role one it is a freshness bound; in roles two and three it is part of the behaviour. Deciding it later means deciding the role later. ## Why the role has to be named before the store Stores in this class do not all offer the same things. Some keep nothing across a restart; some reclaim entries under memory pressure while others refuse further writes at the ceiling; some have no mechanism for delivering to listeners at all. Each of those differences matters for one role and is irrelevant for another, so a review that names the role has narrowed the field of stores before anybody compares them - and a review that skips it may discover, after the store is chosen, that the role it actually wanted is not on offer.
- Why is "is there a system of record behind it?" better asked than assumed?Because the assumption is usually inherited rather than checked. Entries written directly by a process, computed once and never recomputed, or incremented in place have no source to be re-read from. Asking the question turns derivability into a stated precondition somebody owns, instead of a belief that is discovered to be false during an incident.
- The team answers "it is just a cache, but also we keep the in-flight claims there" - what do you do with that?Treat it as two entry populations on one deployment and label them separately. The claims decide the strict settings: what survives a restart, and whether entries may be reclaimed under memory pressure. Then decide whether those settings are acceptable for the whole deployment or whether the populations should be separated.
- Which identifying question tells you the design has left this component entirely?Whether anyone who was not connected must still receive the item later, acknowledge it, or replay it. Delivery to current listeners with nothing retained is the transient transport role; retention and acknowledgement are a retained log, a different component with different guarantees and different owners.
saying these in an interview costs you the question
- Answers "what if it goes down" without saying what the tier holds.
- Assumes derivability rather than asking who owns it.
- Treats any deadline on an entry as a freshness bound.
- Calls two entry populations one thing because they share a deployment.
- Chooses the store before naming the role it must fill.