What does the customer mean by real time?
The same phrase can mean a fresh status page or a new transaction system.
The question
Larkspur Logistics wants a real-time portal within 42 days. The transaction API cannot change for 42 days. The company, people and results in this exercise are invented.
- SponsorWe want a real-time portal. Please recommend the architecture.
- Core ownerThe transaction API is frozen during the first phase. We have not agreed what the new portal must do.
“Define the customer behavior before committing to a design.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Which question comes before the component choice?
What would you do here? Open the move you’d make.
Ask which model or product the customer wants
Tempting, but it misses something. This chooses a product before defining behavior.
Ask what users must do and how fresh it must be
The strong move. This defines the behavior the design must satisfy.
Promise subsecond transactions
Tempting, but it misses something. The customer has not asked for transaction writes.
See how a strong candidate says it
“I would ask which decision the portal user must make and how fresh the information must be. A product name or a latency promise cannot answer that.”
Why it works: Discovery must resolve an observable customer behavior.
Step 2: Operations now asks for read-only status no more than 15 minutes old. Which boundary fits?
What would you do here? Open the move you’d make.
Examine a read projection while keeping core writes
The strong move. This can respect the transaction API freeze.
Replace the transaction API in this phase
Tempting, but it misses something. That conflicts with the stated freeze and adds scope the read request does not require.
Use yesterday’s batch export
Tempting, but it misses something. A daily export cannot meet a 15-minute freshness target.
See how a strong candidate says it
“I would keep transaction writes in the existing core and examine a read projection. Its freshness and operating claims still need evidence.”
Why it works: A read requirement can have a different boundary from transaction replacement.
Step 3: The projection model fits 11 copy/validation days and $13,000 per period. What remains?
What would you do here? Open the move you’d make.
Call the architecture accepted
Tempting, but it misses something. The numbers do not establish event freshness or customer acceptance.
Replace the full transaction stack instead
Tempting, but it misses something. The clarified need is a status read, and the broader design has not been justified.
Test delay, reconciliation and operating ownership
The strong move. These are the remaining claims needed for this proposed boundary.
See how a strong candidate says it
“I would check the full source-to-portal delay, reconciliation and operating ownership. Time and cost allowances do not prove that users see sufficiently fresh status.”
Why it works: The arithmetic establishes a planning limit, not acceptance of behavior.
Step 4: The delayed-feed fixture produces 18-minute-old status. What do you recommend?
What would you do here? Open the move you’d make.
Launch because average freshness is acceptable
Tempting, but it misses something. The customer requirement was not an average-only claim.
Hold and assign the feed fix or an explicit requirement change
The strong move. This keeps the recommendation within the observed customer requirement.
Change the label to near real time
Tempting, but it misses something. Copy does not change the customer’s required behavior.
See how a strong candidate says it
“Hold this path. The 18-minute observation exceeds the 15-minute requirement. Assign the feed fix or a deliberate requirement change to its owner.”
Why it works: A new measurement can reject a design whose cost and copy model fit.
The answer, in short
- Decision
- Keep the transaction boundary; do not expand the failing read path.
- Because
- The proposed read projection fits the modeled cost and copy allowance, but its 18-minute result fails the 15-minute target.
- What would change it
- A representative delayed-feed result within the agreed target and accepted operating ownership could support a new commitment.
Common traps
- Choosing a product before defining the customer behavior.
- Calling an arithmetic fit a customer acceptance.
- Changing a label instead of fixing the requirement conflict.
Check your answer
- Did I define what the user must do?
- Did I respect the transaction boundary?
- Did I distinguish modeled limits from observed behavior?
- Did I respond to the delayed-feed result?
Last reviewed Nov 10, 2026