Module 21 · Lesson 2 of 11Free

A 45-minute interview framework

Level

Beginner

Topic

System design interviews

Reading time

15 min

Twenty minutes into a 45-minute interview, you have drawn twelve boxes for Kartly. The interviewer asks, “What happens when checkout succeeds, but the customer never receives the response?”

You have not explained checkout yet. How do you use the remaining time to show engineering judgment rather than finish a diagram?

The answer starts before you draw: organize the conversation around evidence, then adjust the time you spend producing it.

Checkpoints matter more than minutes

A schedule can remind you to move forward. It cannot tell you whether the design makes sense.

Use the following schedule as a practice default. The times are this lesson’s recommendation, not an employer’s scoring system.

This table assumes the design discussion gets the full period. If introductions or questions share that time, shorten the working budget first.

Actual formats differ. Atlassian’s handbook describes a 60-minute systems design session, not a universal 45-minute format.^{2Atlassian engineering interview handbookAtlassian}

Before starting, ask how much time is available for design and whether the interviewer has a preferred focus. Then choose how firmly to follow your schedule.

The schedule now has a purpose. Next, you need to decide what belongs inside it.

Agree on one user journey

Use Kartly at its later-course scale: separate services, replicated data and sharded storage. You are not rebuilding the whole store.

For this practice scenario, the prompt is “Design Kartly’s checkout.” Your first task is to make that smaller:

“I’ll focus on turning a cart into a confirmed order. Should stock reservation and payment authorization be included?”

Assume the interviewer says yes. Recommendations, seller onboarding and delivery routing stay outside the design.

Ask what “confirmed” promises. For this scenario, assume it means stock is reserved and payment authorization is recorded. A pending attempt is not yet a confirmed order.

That distinction changes the design. You cannot treat a successful HTTP response from any one service as proof that checkout is complete.

Microsoft’s guidance recommends clarifying ambiguity and making a plan before implementing a solution.^{1Technical interviewsMicrosoft, Microsoft Careers} Here, the useful result is an agreed promise, not a long list of questions.

Write down:

• Journey: submit cart, complete checkout, retrieve the result.
• Must preserve: one checkout attempt must not create duplicate orders or duplicate payment authorizations.
• Allowed delay: an uncertain attempt may remain pending while its outcome is checked.
• Outside scope: product discovery and delivery assignment.

These are illustrative requirements, not facts about a real store. A different answer about pending orders would change the next stages.

The previous lesson, How design interviews are evaluated, explains the evidence behind evaluation. Here, you are arranging opportunities to show that evidence.

Once the promise is clear, estimates should help you locate pressure, not delay the design.

Estimate only what changes choices

Kartly’s later-course traffic includes about 100,000 requests a second at a festival peak. That is total traffic, not checkout traffic.

Do not quietly size payment processing for every product-page request.

Ask for the checkout share or label an assumption. If the interviewer supplies a checkout peak, use it directly. Explain what you need the number for:

“I want to distinguish pressure on order creation from pressure on browsing. Those paths need different scaling discussions.”

Then calculate only what informs the next decision. Storage might matter if order history must remain online for years. Simultaneous attempts might matter if a downstream call stays open for a long time.

You do not need every calculation in every interview. Stop when you can explain what the result changes.

For example, a traffic estimate alone cannot prove that a database will handle the workload. Query shape, contention and measured capacity remain unknown.

Say what would need measurement rather than inventing a server count. Estimation under time pressure develops that technique.

Leave this stage with a short conclusion: which path deserves capacity attention, and which uncertainty still needs testing. Now make that path work.

Trace one request before expanding

By about minute 20 in this practice schedule, aim to explain checkout from submission to a visible result.

Start with responsibilities already present in later-stage Kartly. Do not add a new component merely to fill the diagram.

Walk through one proposed sequence:

1. The app submits a checkout attempt with an idempotency key, identifying retries of that same attempt.
2. Checkout records a pending order and associates it with the attempt.
3. Checkout asks inventory to reserve stock.
4. Checkout requests payment authorization.
5. Checkout records confirmation only after the required outcomes are known.
6. The app receives the result or retrieves the attempt’s status later.

This is a starting proposal, not a complete transaction protocol. Stock expiry and partial failure remain unresolved. Naming those gaps gives the next stage a concrete target.

Use the diagram to support this explanation. Point to the owner of each step and name the data crossing each boundary.

If the interviewer cannot tell where a pending attempt lives, adding a cache will not fix the explanation. Presenting the high-level design covers that presentation in detail.

The normal path is now visible. The next choice is where to test it hardest.

Spend depth on the largest risk

Return to the opening question. Payment authorization succeeded, but the response disappeared. The customer taps again.

The tempting move is to add more infrastructure. The useful move is to inspect what the design knows about that attempt.

Use a short chain of questions:

• Does a retry find the existing attempt, or create another?
• Can simultaneous requests both start the same work?
• Which identifier reaches the payment boundary?
• After a timeout, where does checkout learn the actual outcome?
• What does the customer see until that outcome is known?

Do not answer “idempotency” and move on. The key identifies intent; your design still needs rules for storing, enforcing and recovering that intent.

For this proposed design, an unresolved payment call leaves the attempt pending. A recovery process checks the payment outcome before deciding what to do next. Explain who owns that process and what happens if it also fails.

You can stop before implementation code if the mechanism is clear. The full engineering problem belongs in Design: an e-commerce checkout.

Amazon’s preparation guidance explicitly invites candidates to ask questions that complete and validate their designs.^{3SDE II Interview PrepAmazon, Amazon Jobs} Use that opportunity to check whether the chosen depth is useful:

“The unresolved payment outcome is the main correctness risk. Would you like me to continue into recovery or examine inventory contention?”

Depth earns its time by answering a requirement. It should not become a second, disconnected design.

Recover time by cutting scope

Suppose you reach minute 28 with only a partial request flow. You have 17 minutes left in this practice scenario.

Do not speak faster. Reduce the remaining work.

1. State where you are: “The checkout path is outlined, but confirmation and recovery need detail.”
2. Name the priority: “I’ll finish that path before discussing regional expansion.”
3. Complete the missing normal steps.
4. Test one important failure.
5. Keep a short closing period.

This is better than pretending nothing changed. It also gives the interviewer a chance to redirect you.

If a follow-up arrives early, answer the question rather than defending your schedule. Atlassian describes follow-ups that introduce different approaches or tradeoffs to assess adaptation.^{2Atlassian engineering interview handbookAtlassian}

Connect the answer back to the design:

“That changes the confirmation rule. I’ll update the order flow before continuing.”

Keep a small “later” list for deferred topics. Write “reservation expiry: unresolved,” not “inventory handled.” A visible gap is more honest than a false guarantee.

The remaining time should make the design easier to judge, not merely larger.

Close with decisions and limits

Do not use the final minutes to introduce another major subsystem.

For the Kartly practice, a useful closing sounds like this:

“We scoped checkout rather than the whole store. Confirmation requires a stock reservation and a recorded payment authorization. Retries identify the same attempt. An uncertain payment outcome remains pending until checked. Reservation expiry is still unresolved; I would examine that next.”

This separates the promise, the proposed mechanism and the unfinished work.

If the interviewer reserves the end for your questions, finish the design summary before that period. If discussion continues, use a shorter summary rather than interrupting an active technical question.

Try it yourself

Take five minutes to reconstruct the Kartly flow on paper. Then explain it aloud without naming any technology products.

For each step, name its owner, stored outcome and possible failure. Mark any step you can describe only as “the backend handles it.”

Use those marks to choose your next practice topic. A recorded practice session is useful only if you review what you actually explained, not whether the timer ended neatly.

This framework depends on agreeing on the right problem first; Clarifying requirements in an interview examines that opening conversation next.

Common mistakes

• Treating the schedule as a rubric. The ranges organize practice; they do not establish an employer’s scoring rules.
• Finishing estimates without using them. State the resulting design decision, or stop calculating.
• Drawing everything before tracing anything. Explain one complete user journey before adding supporting systems.
• Skipping failure because time is short. Cut a secondary feature instead of leaving the main promise untested.
• Claiming unfinished work is solved. Name the missing mechanism and the next question it raises.

Check your understanding

Summary