Architecture Narrative

One system, three distances

An interviewer asks for the architecture of a project you know well. You can see the whole thing: services, stores, queues, scheduled jobs, migration adapters, dashboards, alerts, dependencies, and years of accumulated decisions. You have perhaps forty minutes. You do not yet know which five minutes the interviewer cares about.

The hard part is not remembering the system. It is choosing the right distance from it.

At first, the interviewer needs to know what the system promised and where you stood in relation to it. Once oriented, they need to see one consequential path move through the architecture. Only then can details about consistency, failures, rollout, cost, security, and rejected designs prove anything. Giving all three views at once produces a tour of boxes. Staying at one distance makes the answer either vague or exhausting.

Prepare the architecture at three resolutions:

• a two-minute promise that establishes purpose, shape, and ownership;
• a ten-minute path that follows the system through real work;
• a forty-minute deep dive in which questions expose decisions, failure behavior, and production evidence.

These are not three speeches. They are three views of the same causal spine.

The modeled reconciliation project from the previous chapter will carry the work here. Its details are fictional but technically representative. Replace them with facts from your own dossier.

In two minutes, give the architecture a reason to exist

A component inventory is a weak opening:

We had three services, Kafka, Redis, Postgres, and a nightly job.

Every noun may be accurate, yet the listener has no basis for deciding which one matters. Start with the behavior the architecture had to preserve.

Finance operations reconciled partner payment events through a nightly batch.
Retries and late adjustment files created duplicate exceptions and manual work
during month-end close.

We moved ingestion behind an idempotent event boundary and wrote auditable
checkpoints to a ledger service. From finance's point of view, a retried event
should affect reconciliation once, while genuinely new adjustments should
remain visible rather than being mistaken for duplicates.

I led the ingestion boundary, idempotency model, and partner-by-partner rollout.
The platform team owned the ledger service, and finance owned the matching
rules. The most useful place to go deeper is the boundary decision, because
deduplicating later in the batch was cheaper but would not have stopped the
exception work at entry.

This opening gives the listener the before-state, the system promise, the architecture’s broad shape, your actual boundary, and one live decision. It also avoids a common technical blur. The design does not claim that a distributed pipeline performs every operation exactly once. It claims a specific user-visible effect and points to the state that supports it.

The two-minute view should survive the removal of product names, scale claims, and fashionable technology. If it becomes unimpressive without those nouns, the project pressure is still missing.

In ten minutes, let the system move

Now follow the event that carries the risk. For reconciliation, the path is more revealing than a catalogue of components:

partner event
  -> authenticate and normalize at ingestion
  -> derive and claim the partner-specific idempotency key
  -> write an auditable ledger checkpoint
  -> route unmatched events and late adjustments for review
  -> expose lag, retries, and exception categories to operators

Walk that line in order. At each boundary, add only the detail needed to answer one of four questions:

• What state changes here?
• Who owns the state or decision?
• What can fail, repeat, or arrive out of order?
• How would an operator know and recover?

The ingestion step earns explanation because partner formats and retry semantics differ. The idempotency record earns explanation because it carries the correctness claim. The ledger boundary earns explanation because another team owns it and because checkpoints must remain auditable. Exception routing earns explanation because late adjustments are valid business events, not duplicates to discard. Flags and shadow comparisons earn explanation because month-end close makes a global cutover irresponsible.

Ordinary framework layers probably do not earn time. Neither does every field in the checkpoint schema. The ten-minute view succeeds when the listener can predict where the difficult questions live.

Near the end of the walkthrough, offer a small branch menu:

The three useful branches are the idempotency invariant, the checkpoint model,
and the rollout after late adjustments broke our first assumption. I owned the
first and the rollout; I can explain the ledger dependency, but I did not own
its storage design.

That invitation is not an attempt to control the interview. It makes the map explicit, gives the interviewer a choice, and prevents you from spending ten minutes on a branch they do not need.

Draw the answer, not the production estate

A project diagram is a navigation aid. Draw the upstream actor, the boundary your team owned, the durable state that carries correctness, the important dependency, the downstream user, and the control you expect to discuss.

Label arrows with verbs: normalizes, claims key, writes checkpoint, routes adjustment, alerts operator. A verb forces you to explain behavior. A page of noun-labeled boxes invites you to recite inventory.

Leave out framework layers, internal helpers, and historical remnants unless they alter the decision. Show another team’s component when its ownership, contract, or failure mode constrains yours. If a migration is central, the old and new paths may both belong; otherwise, drawing every retired path burdens the listener with archaeology.

When the interviewer asks you to zoom out, return to the promise. When they ask you to zoom in, mark the exact boundary on the drawing before adding detail. The diagram then preserves orientation while the conversation changes depth.

The deep dive follows pressure

The forty-minute version is not the ten-minute version with more boxes. It is what happens when the interviewer presses on a claim.

Suppose the listener asks why idempotency lived at ingestion rather than in the nightly batch:

Batch deduplication was the smaller migration and reused an ownership boundary
we already understood. Its weakness was timing: duplicate events would still
reach finance's exception queue before the batch removed them.

We accepted the extra schema work and replay testing at ingestion because that
was the first place we could neutralize retries. We claimed a partner-specific
key before downstream processing and made retry attempts observable there.
That did not solve late adjustments. Those were new business events, and the
first rollout group showed that our original model did not represent them
cleanly.

This answer remains attached to the original promise. It gives the rejected path its fair advantage, identifies the binding constraint, names the cost of the chosen design, and stops before pretending that idempotency solved every temporal problem.

Other questions should apply pressure in the same way:

• A correctness question follows the key, checkpoint, replay behavior, and boundaries of the claim.
• A reliability question follows the first failure that an operator can observe, the degraded behavior, and the recovery path.
• A scale question follows the resource or coordination point that becomes scarce, not a memorized list of caching techniques.
• A security or privacy question follows sensitive data and authority across boundaries.
• A cost question follows the expensive behavior and the choice that made it acceptable.
• An ownership question separates what you decided, influenced, implemented, inherited, and depended on.

You do not need to predict the sequence. You need enough command of the spine to show how each branch changes the system’s behavior.

Let the miss alter the architecture

The late-adjustment failure is not a behavioral anecdote pasted onto a technical answer. It changes what the architecture means.

During the first partner ramp, an adjustment arrived after the original checkpoint. The system treated the case poorly because the model had been shaped around retries of an existing event. The team paused the ramp, distinguished corrections from retries, added an adjustment path and replay cases, and exposed the category to finance operations.

That sequence proves more than a smooth launch story could. It shows that the rollout was reversible, that observability led to action, that a user workflow belonged in the domain model, and that the original invariant had a boundary. It also creates an honest revision:

I would keep the staged rollout and the idempotency boundary. I would bring
finance operations into schema review before the first partner ramp, because
their exception categories were part of the model, not merely a dashboard
concern.

Production evidence need not be an exact metric. It may be a paused rollout, fewer log-inspection requests, a class of retries becoming visible at ingestion, a recovery drill, or an operator completing work without an engineer. Say what was directly observed, what is inferred, and what cannot be attributed to this project alone.

Interruption is part of the form

An interviewer may ask for a higher level halfway through a schema explanation, challenge an alternative, or discover that a decision belonged to someone else. Treat the interruption as a change of resolution.

Useful responses are short because they restore a shared position:

• “At the highest level, the promise was that retries would not create a second finance effect. This key is where our boundary enforced that.”
• “The batch design was a real option because it shipped sooner. It failed our timing constraint.”
• “I owned the ingestion model and drove this review. The platform team chose the ledger’s storage design.”
• “I do not know that dependency’s internal recovery mechanism. Our contract exposed this failure, and our service responded by doing this.”

Precision is stronger than bluffing. If you do not know a detail, state the edge of your knowledge and explain the contract or evidence you did own.

Sanitize before the answer becomes fluent

Replace company, customer, partner, product, and internal service names with neutral roles. Round or describe sensitive scale. Remove credentials, contract terms, exploit details, unreleased strategy, incident identifiers, and metrics you are not free to disclose.

Keep the engineering. “A partner retried payment events and created duplicate reconciliation work” preserves a mechanism. “We had a vendor issue” does not. If the mechanism itself cannot be discussed safely, choose another project.

Sanitization also protects accuracy. Rehearse the safe version from the start so that pressure does not make you alternate between a vague public story and a confidential private one.

Rehearse expansion, not scripts

Close the dossier and try the two-minute version aloud. Draw the risky path from memory and walk it for ten minutes. Then let another person interrupt: ask why the simpler design lost, what fails first, who owned the decision, how recovery worked, and what changed after launch.

Open the dossier only after the attempt. Repair the source rather than decorating the speech:

• If the opening became a component list, sharpen the system promise.
• If the walkthrough branched everywhere, choose one event or request that carries the risk.
• If the deep dive became abstract, recover a real alternative, accepted cost, failure, or production observation.
• If “I” and “we” drifted, redraw the ownership boundary.
• If the answer became empty after sanitization, use a different project.

Repeat until shortening the answer preserves causality and expanding it adds proof rather than inventory. The architecture is ready when the interviewer can choose the distance and still encounter the same system.

Related links

• The Project Dossier
• Decision and Trade-Off Log
• High-Level Architecture and Data Flow
• Reliability and Failure Engineering
• Migrations and Backward Compatibility
• Communicating Trade-Offs Like a Senior Engineer