Before changing data in a system design answer, name its authoritative owner. A delivery screen, cache and customer profile can all show an address without having the same right to update it.

This interview exercise uses a fictional address update copied to a delivery view after a delay. It is about ownership and consistency, not a legal rule for handling personal information.

Which address are we talking about?

Ask whether the user is changing the saved profile address, the address for one unshipped order or a historical delivery record. Those can be separate business facts. Updating a profile should not automatically rewrite where an old parcel was actually delivered.

Define the field's meaning before choosing a table or event. A system with several copies is not necessarily wrong; a system with unclear meanings is difficult to change safely.

What can the delivery view promise?

If it updates asynchronously, it may briefly display an older value. Decide whether that delay is acceptable for viewing and whether a consequential action must recheck the authoritative address.

For example, an order-confirmation operation may need the latest permitted delivery address even if a general list page tolerates a delay. The consistency requirement belongs to the operation, not to a slogan that every screen must use the same strategy.

How do you handle a competing edit?

A version or concurrency token can help detect that a record changed after the caller read it. The server can reject or reconcile a stale update according to the business rule. A last-write-wins policy is a choice with consequences, not an automatic correctness guarantee.

Explain what the user sees when a conflict occurs. Asking the user to review the newer value may be safer than silently overwriting it. Test the actual storage mechanism that enforces the check.

What does a useful data flow look like?

Fictional profile-address change:
1. Authenticate the caller and check permission.
2. Validate the proposed profile address.
3. Apply the change to the authoritative profile with a version check.
4. Record the supported update event or propagation work.
5. Refresh the delivery view through its documented process.
6. Show whether the view is current or still catching up.

This is a reasoning outline, not a claim that an event bus is mandatory. A smaller application may use a simpler supported workflow. Reuse its architecture instead of adding infrastructure without a need.

What about migration?

When moving ownership, identify readers, writers, validation rules and existing copies first. Backfill data through an agreed process and verify counts and representative records. Plan how to recover if a new reader sees incomplete data.

Do not delete the old field immediately after one successful example. Check the actual consumers and compatibility window. A safe transition includes evidence that no required writer still depends on the old meaning.

Questions worth practicing

  • Which service can change the value?
  • Which copies are derived, and how fresh must they be?
  • What happens when propagation fails?
  • How are stale updates detected?
  • Which historical values must remain unchanged?
  • How will the user recognize a completed update?

Draw one change from request to storage to every visible copy. If you cannot explain a consumer, record it as an unknown rather than guessing. That makes the answer grounded and gives the next investigation a clear purpose.

References and next practice

careerservices.fas.harvard.edu — career · developer.mozilla.org — http

Browse interview topics · Practise a question in Interview Challenge · How to Prepare for an Interview