If You Can't Draw the Boundary, You Don't Have an Architecture

The boundary question ended my whiteboard round before it started. The interviewer asked where my system ended. I listed components. He said I had just described the whole company.

He was right.

Watch the 40-second version first: Q2: System Design Interviews Start With the Boundary

Your architecture starts at the word no

Interviewers ask "where does your system end" because that is where the thinking lives. A list of components is a shopping list, not a design. Tradeoffs only exist at seams: the moment you say "auth is not mine, it is the identity provider, and this token contract is all that crosses the line," you have made a real architectural decision. The candidate who never draws the dashed box is really saying: I have opinions about everything and responsibility for nothing.

Here is the uncomfortable part. Most candidates CAN name the technical boundaries. Auth, payments, the CDN. They say those words and feel done. But they never say the part that actually matters in a real company: who owns the other side of the line.

The seam you always forget is the org seam

The boundary that kills real projects is never technical. It is the team boundary. Your storefront shell ends where the platform team's design system begins. Your checkout flow ends where the payments team's webhook contract begins. Your "simple read" from another team's service ends the night they ship a breaking change and nobody told you.

If you cannot name the owner on the other side of the line, you have not drawn a boundary. You have drawn a wish.

Interviewers know this. When they ask about the boundary, they are listening for one thing: does this person know the difference between what they build and what they depend on? Seniors answer in owners and contracts. Juniors answer in boxes.

The 4-seam checklist (say it out loud before you draw anything)

1. Auth. Not yours. Name the provider. State exactly what crosses the line: tokens in, sessions out.
2. Payments. Not yours. Name the vendor. State the contract: webhooks, idempotency keys, who retries.
3. Data you do not own. Which reads come from other teams' services, and who gets paged when they break at 2 a.m.
4. The shell. What IS yours, the thing in the middle, in one sentence. If it takes two sentences, your boundary is wrong.

Everything outside the dashed box gets a name and an owner. Everything inside gets your design. That is the whole exercise.

One rule to tape to your monitor

Get the boundary wrong and every diagram after it is fiction. You are not designing components. You are defending a perimeter. Draw the dashed box first, then earn the right to fill it in.