Iterative Design Process

Imagine you're designing a house. Would you start by selecting the perfect doorknobs, or by sketching the floor plan? The answer seems obvious—yet in software engineering, many developers instinctively dive into implementation details before establishing the overall structure.

High-level first, then deep dive is a fundamental principle that ensures your detailed decisions serve the broader architectural vision rather than constraining it. This approach mirrors how the most effective engineers think: they establish context before making commitments, understand the whole before optimizing the parts, and defer detailed decisions until they have sufficient information to make them well.

When engineers start with component-level details, several predictable problems emerge:

Local optimization at the expense of global coherence

When you optimize individual components in isolation, you often make decisions that conflict with system-wide requirements. A database schema optimized for one query pattern may perform terribly for others. A service API designed for one consumer may be inefficient or awkward for others.

Integration difficulties

Components designed independently often don't fit together cleanly. Interface mismatches, data format inconsistencies, and conflicting assumptions about state management create friction at integration boundaries. These issues are expensive to resolve after components are built.

Premature commitment to implementation details

Detailed decisions made early constrain options for later decisions. If you commit to a specific database schema before understanding query patterns, you may find yourself fighting your own schema. If you define API contracts before understanding all consumers, you may need breaking changes later.

Difficulty seeing the forest for the trees

When heads are down in implementation details, it's easy to lose sight of whether the system actually solves the original problem. Teams can spend weeks perfecting a component that, in retrospect, shouldn't exist at all.

High-level design establishes the structural foundation for everything that follows. At this phase, you're answering fundamental questions:

What are the major components of the system?

Identify the primary building blocks. For a typical web application, this might be: clients, API gateway, application servers, databases, and external services. For a data pipeline, it might be: data sources, ingestion layer, processing engine, storage, and consumers.

How do these components interact?

Define the communication patterns. Do components communicate synchronously or asynchronously? What protocols do they use? Which components depend on which others?

Where does data live and how does it flow?

Identify the sources of truth for different data domains. Trace how data moves through the system from ingestion to final use. Understand which components read vs. write which data.

The right level of abstraction:

High-level design deliberately omits detail. You don't specify:

• Exact API endpoints or method signatures
• Database table schemas
• Implementation algorithms
• Specific technology versions
• Detailed error handling strategies

This isn't laziness—it's strategic. Deferring these decisions until you have more context leads to better decisions. The high-level design establishes constraints and direction while leaving room for informed detailed decisions later.

Once high-level architecture is established, you progressively elaborate details through structured decomposition. This is not a single step but a series of refinements, each adding more specificity while maintaining coherence with higher levels.

Level 1: System context (established above)

• The system as a black box
• External actors and systems

Level 2: Container/component level

• Major deployable units (services, applications, databases)
• How containers communicate
• Responsibility allocation

Level 3: Component internals

• Classes, modules, or layers within each container
• Internal APIs and interfaces
• Data models within scope of component

Level 4: Implementation detail

• Algorithms and data structures
• Specific library choices
• Error handling and edge cases

Applying progressive elaboration:

At each level, you complete the design at that level before moving deeper. For each component identified at Level 2, you complete Level 3 design before implementing Level 4 details. This ensures:

1. Decisions at each level are informed by context from above — You know how a component fits into the larger picture before designing its internals

2. Integration points are defined early — By the time you're implementing details, the interfaces between components are already established

3. Parallel work is possible — Once Level 2 is complete and interfaces defined, teams can work on different components independently

4. Review and validation happen at appropriate abstraction — Architects can review Level 2 designs without understanding every implementation detail

System design interviews explicitly reward the high-level first approach. Interviewers want to see that you can think at multiple levels of abstraction and that you consciously manage the design process.

The ideal interview flow:

Phase 1: Requirements (3-5 minutes)

• Clarify functional requirements
• Understand scale requirements
• Identify key non-functional requirements

Phase 2: High-level design (10-15 minutes)

• Draw the major components
• Explain data flow for primary use cases
• Discuss high-level technology choices
• Address key non-functional requirements at architectural level

Phase 3: Deep dives (15-20 minutes)

• Go deep on specific components (often interviewer-directed)
• Discuss detailed data models
• Address scaling, consistency, and failure handling
• Explore trade-offs in detailed decisions

Signaling your approach:

Effective candidates explicitly communicate their design process. Saying things like:

• "Let me start with a high-level view before diving into details"
• "I'll draw the major components first to make sure we have the right structure"
• "Before we go deeper on this component, let me make sure we've captured the main flow"
• "I'd like to spend the next few minutes on the overall architecture, then we can deep dive on any component you're interested in"

This communication shows process maturity and makes you easier to evaluate. The interviewer knows where you are in your design process and can guide the conversation appropriately.

Sometimes stakeholders (or interviewers) ask detailed questions before you've established the high-level design. Handling this gracefully is an important skill.

Strategy 1: Acknowledge and defer

"That's a great question about the database schema. I want to make sure I have the right high-level structure first, then I'll come back to that with full context. Let me note it here..."

This shows you heard the question and will address it, while maintaining your structured approach.

Strategy 2: Quick answer, then return

"For the database, I'm thinking relational since we have structured data with relationships. I'll elaborate on the schema once we've covered the overall flow—but does that direction make sense?"

This provides enough information to address immediate concerns while not derailing into details.

Strategy 3: Use the question to inform high-level design

"That question about concurrent access makes me realize we should discuss the consistency requirements upfront. What level of consistency does the system need?"

This turns a detail question into a requirements clarification, which is appropriate at the high level.

When to break your own rule:

Occasionally, a detail question reveals a fundamental constraint that changes the high-level approach. If someone asks "How will you handle 10 million writes per second?" when you drew a single database, that's not a detail question—it's revealing that your high-level design doesn't address a critical requirement.

Recognize when a question exposes a high-level gap. In these cases, revise your high-level design rather than deferring the question. Flexibility in your process, applied with judgment, is more valuable than rigid adherence.

Experienced engineers recognize recurring patterns at the high level. Familiarity with these patterns accelerates design work and improves communication.

Request-Response Pattern

• Client makes request, server processes, returns response
• Synchronous communication
• Simple to reason about; blocking limits scale
• Use for: user-facing APIs, real-time requirements

Event-Driven Pattern

• Producers emit events; consumers react asynchronously
• Loose coupling between components
• High throughput; eventual consistency challenges
• Use for: high volume, decoupled processing, analytics

Pipeline Pattern

• Data flows through sequence of processing stages
• Each stage transforms or enriches
• Clear separation of concerns; latency from stages
• Use for: data processing, ETL, machine learning

Combining patterns:

Real systems often combine multiple patterns. A microservices architecture might use request-response for user-facing APIs and event-driven patterns for inter-service communication. A pipeline might have a request-response API for submitting data and event-driven processing internally.

The key is to apply patterns consciously and understand the trade-offs of each choice. Pattern recognition at the high level accelerates design—you can quickly evaluate "Is this a pipeline problem or a request-response problem?" based on the characteristics of each pattern.

Once high-level architecture is established, deep dives explore specific components or aspects in detail. Effective deep dives are focused, structured, and always connected to the high-level context.

Technique 1: Follow the data

Trace specific data through the system end-to-end. Start with how it enters the system, follow it through each processing step, and end with how it's stored and accessed. This reveals:

• Interface requirements between components
• Consistency and durability requirements
• Error handling needs
• Performance bottlenecks

Technique 2: Stress the design

Ask "what happens when..." for each component:

• What happens at 10x current load?
• What happens when this component fails?
• What happens when this database is slow?
• What happens when network partition occurs?

Stressing the design reveals assumptions and failure modes before they occur in production.

We've explored the methodology of approaching system design from broad to specific. Here are the key insights:

What's next:

High-level design is based on assumptions about requirements, scale, and constraints. But assumptions can be wrong. The next page covers how to validate assumptions throughout the design process—ensuring your architecture is grounded in reality rather than speculation.