Adapting Known Designs to New Prompts

The familiar answer that stops fitting

Design a notification digest for a multi-tenant collaboration product. People create documents, assign tasks, mention colleagues, and comment in shared workspaces. Each user may receive an in-app digest or an email every morning, subject to workspace policy and personal preferences.

The prompt sounds like a feed. Both systems ingest events, choose recipients, and assemble a personalized view. It is tempting to draw a fan-out service, per-user timelines, a ranking layer, and a read API. That answer is not absurd. It is dangerous because it becomes plausible before the product promise is clear.

Now the interviewer adds four details:

• removing a person from a private workspace must prevent its events from appearing in tomorrow’s digest;
• an unsubscribe must take effect before the next email is sent;
• each daily email should be delivered at most once, even when workers retry;
• support must be able to explain what was sent and repair a missed delivery.

The feed analogy has done its useful work: it noticed event distribution. It has also reached its limit. A browseable feed is a changing projection that a user can refresh. A digest is a scheduled artifact with a recipient, a cutoff, a delivery decision, and an audit trail. Freshness, ranking, and failure mean different things once the system makes that commitment.

The task is therefore not to forget known architectures. It is to remember them at the right level: as responses to particular pressures.

Begin with the promise

Before choosing storage or queues, say what the system owes the user. For this prompt, a digest is a bounded summary of events the recipient may see at send time, filtered by current delivery preferences, generated for one schedule window, and recorded well enough to suppress duplicates and investigate failures.

That sentence decides more than a list of components would.

“May see at send time” means authorization cannot be frozen when an event is created. “Current delivery preferences” means an old fan-out entry cannot override an unsubscribe. “One schedule window” gives generation a stable identity. “Suppress duplicates” requires delivery state, not merely a retry queue. “Investigate failures” requires the system to retain the basis of the decision without turning every email body into permanent, broadly accessible log data.

Clarifying questions should search for the point where the analogy breaks:

• Is the product promising a live surface, a scheduled artifact, a booking, a search result, or a completed action?
• Which state is canonical, and which state can be rebuilt?
• Whose authority is checked when work is created, assembled, and delivered?
• What may be stale, and what becomes harmful when stale?
• What must happen once, in order, or not at all?
• When the system is wrong, can it refresh, replay, regenerate, compensate, or only apologize?

A useful interview answer makes the borrowed analogy explicit and then gives the interviewer permission to watch it change:

This begins like a feed because both systems distribute events to interested
users. The digest makes a different commitment: it creates and delivers a
scheduled artifact. I would keep event ingestion and recipient targeting, but
retest authorization and preferences at assembly and make delivery state
explicit.

Follow one digest through the system

Suppose Maya belongs to two workspaces and receives a digest at 08:00 in her time zone. During the previous day she was mentioned in a private design document, assigned a public task, and removed from the private workspace. At 07:58 she disables email while leaving the in-app digest enabled.

The ingestion path first records domain events with stable identifiers, workspace and resource ownership, event time, and the canonical object version. This log is useful for replay and aggregation, but it is not proof that Maya may receive an event tomorrow. Membership and object permissions can change after ingestion.

A scheduling service creates one generation job for Maya’s digest window. The job identifier can be derived from the recipient, channel, local schedule, and window:

DigestWindow
  recipient_id, channel, window_start, window_end, schedule_version

CandidateEvent
  event_id, workspace_id, resource_id, resource_version, occurred_at

DeliveryIntent
  digest_id, recipient_id, channel, preference_version
  content_hash, status, provider_message_id, attempt_count

The assembler fetches candidate events, then checks current workspace and resource authority before rendering. Maya’s private-document mention is excluded because her membership was revoked. The public task remains. The assembler may rank, group, or collapse repeated activity, but those are presentation policies over an already authorized set.

Immediately before creating a delivery intent, the service checks the current channel preference. Maya’s 07:58 change prevents the email intent. The in-app artifact may still be generated because that channel remains enabled. This late check does not remove the need for earlier filtering; it closes the race between assembly and commitment.

The delivery intent supplies the idempotency boundary. A worker may time out after the email provider accepts a request but before the response reaches the worker. Retrying a generic send_email job risks a duplicate. Retrying an intent with the same idempotency key lets the sender query or repeat the same logical delivery. If the provider cannot support that contract, the design must acknowledge the remaining ambiguity and give support a way to inspect it.

The completed artifact records the event and resource versions used, the authorization and preference decision versions, the template version, the content hash, and the delivery result. Sensitive bodies need an explicit retention and access policy; identifiers and hashes are investigative aids, not automatic anonymization.

This architecture still contains feed-shaped parts. Event ingestion, recipient targeting, grouping, and perhaps ranking transfer. Fan-out-on-write to a durable per-user timeline does not transfer cleanly because recipient authority and preferences can change before the scheduled send. The read path has become an assembly path, and the ephemeral feed projection has become a versioned delivery artifact.

Make the failures argue with the analogy

The most revealing follow-ups are not invitations to bolt on generic retries and monitoring. They change a constraint and force a new design decision.

Suppose a workspace deletion is delayed in one event index. Query-time authorization prevents the stale candidate from becoming content, but the index is still wrong. The system needs deletion propagation, a way to find affected projections, and a rebuild path from canonical state. Authorization contains the immediate harm; reconciliation repairs the derived data.

Suppose the scheduler runs twice after a failover. A unique digest-window key should collapse both generation attempts onto the same logical artifact. If the window definition itself changes because a user changes time zone, the schedule version must distinguish the old and new decisions. “Exactly once” is not a property granted by the queue. It is a product-level identity carried through generation and delivery.

Suppose an upstream event is corrected after the digest is sent. The system cannot unsend an email. It can correct the in-app view, record which recipients saw the old version, and decide whether the consequence warrants a correction message. This is where canonical state and delivered history must remain separate. Rebuilding a projection repairs future reads; it does not erase an external effect.

Now suppose product changes the digest into a live notification center. The old feed analogy becomes more useful: low-latency fan-out, unread counters, incremental ranking, and reconnect behavior may earn their cost. Delivery audit may become lighter for ordinary items, while mentions or security alerts retain stronger state. A strong answer does not defend the first architecture. It reruns the reasoning when the promise changes.

A compact map for the next unfamiliar prompt

Only after the digest has exposed the need for it is a reusable vocabulary worth naming.

For any tempting analogy, perform five moves:

1. State why the known system seems relevant.
2. Describe the new product promise in one precise sentence.
3. Name the old constraint that justified each borrowed component.
4. Keep, change, or remove the component after comparing the new constraint.
5. Follow one failure through detection, containment, and repair.

The categories in the figure keep the comparison honest. Identity asks who owns the resource and who may act. State separates canonical facts from rebuildable projections and irreversible effects. Flow makes ordering, idempotency, and backpressure visible. Freshness says what may lag. Failure forces the answer beyond detection to recovery.

Scale remains important, but it does not decide consequence. A small internal booking tool may need strong authorization and idempotency. A huge public feed may tolerate stale ranking. Remove global replication, multi-layer caching, or streaming infrastructure when the workload does not justify them; do not discard privacy, money, inventory, or audit boundaries merely because traffic is modest.

Test the method outside the feed family

The method should survive prompts that do not share the digest’s shape.

A document-preview service resembles a video pipeline because both preserve a large original and create read-optimized derivatives asynchronously. Keep the source object, sandboxed conversion, derived artifacts, CDN delivery, and regeneration path. Replace bitrate ladders with thumbnails, page images, extracted text, and search records. Drop playback buffering and segment manifests. The new failure to pursue is a parser defect or deletion race that leaves confidential derivatives behind.

Expert matching resembles ride dispatch because both allocate scarce supply through offers, holds, acceptance, cancellation, and rematching. Keep those workflow states. Replace distance and live GPS with skill, schedule, language, price, trust, and workload. Drop geospatial indexing unless location really constrains service. Then ask how ranking affects expert utilization and fairness rather than importing a driver’s proximity model under new names.

Compliance search resembles a retrieval-augmented assistant because both index private material under permissions. Keep source identity, versions, deletion, permission filtering, citations, and evaluation. If the product promise is evidence retrieval, make exact filters, exports, saved searches, and review history primary; generated prose may be optional or absent. A fluent answer is not an improvement when it weakens auditability.

In each case, the known design supplies a head start. The changed commitment decides where that head start ends.

Practice the change, not the recital

Take a system you know well and adapt it to this prompt:

Design a service that assembles a weekly evidence packet for a regulated
workflow. Reviewers must see the source records they are allowed to inspect,
the packet may be regenerated after corrections, and a submitted packet must
remain auditable.

Give yourself two minutes to name the tempting analogy. Then state the product promise, identify canonical and derived state, and choose one component to keep, one to change, and one to remove. Finally, follow a permission revocation or corrected source record through the system.

Repeat with one variation: the packet must now update live, or submission is now a legal commitment, or reviewers may work offline. If the diagram stays unchanged, the reasoning has probably stopped too early.

The casebook has supplied many architectures worth remembering. Their lasting value is not the arrangement of boxes. It is the relationship between a user commitment and the authority, state, flow, freshness, and repair machinery that keeps it. The next stage of senior judgment is to carry that adapted architecture through review, release, observation, and ownership without losing the reasons it was designed that way.

Related links

• Requirements and Non-Functional Requirements
• Reliability and Failure Engineering
• Collaboration and Multi-Tenant Platforms
• Media Systems
• AI-Native Systems
• The Software Delivery Lifecycle