TECH ENGLISH

System Design Discussions

Learn how to discuss system architecture in English — explain trade-offs, propose solutions, and handle whiteboard discussions with confidence.

Practice Tech Discussions

Scenario Context

Your team needs to design a notification service that handles millions of push notifications per day. You're leading a whiteboard session where you need to propose an event-driven architecture, discuss the trade-offs of using a message queue, and handle questions about fault tolerance and scalability.

Why This Matters for Engineers

System design discussions determine the architecture that your team will build and maintain for years. Engineers who can clearly articulate trade-offs between different approaches — scalability vs. simplicity, consistency vs. availability — become the technical leaders that teams rely on. If you can't explain your design decisions in English, even brilliant ideas will be overlooked in favor of whoever communicates them best.

Essential Phrases

“Let me walk you through the high-level architecture first.”

Starting a design discussion

neutral

“The main trade-off here is between consistency and availability.”

Discussing trade-offs

formal

“I'd propose an event-driven architecture using a message queue.”

Proposing a solution

formal

“What happens if this service goes down? We need a fallback.”

Discussing fault tolerance

neutral

“This scales horizontally — we can just add more consumer instances.”

Explaining scalability

neutral

“We could use a fanout pattern here to decouple the publishers.”

Proposing a pattern

formal

“The bottleneck is going to be the database writes.”

Identifying bottlenecks

neutral

“Let me sketch out the data flow on the whiteboard.”

Switching to visual

casual

“Have we thought about how this handles back-pressure?”

Raising concerns

formal

“I think we're over-engineering this — let's start simple and iterate.”

Advocating simplicity

casual

“What's our expected throughput? That'll drive the choice of database.”

Gathering requirements

neutral

Technical Pronunciation

Word	❌ Common Error	✅ Correct	Tip
Kubernetes	koo-BER-nets	koo-bur-NET-eez	Four syllables — stress on NET. Ends in '-eez' like 'freeze'.
PostgreSQL	post-GRES-kew-ell	POST-gres-kew-ell	Stress on POST. Many just say 'Postgres'.
latency	lah-TEN-see	LAY-tuhn-see	First syllable sounds like 'lay', not 'lah'.
throughput	through-put	THROO-put	Stress on the first syllable. The 'gh' is silent.
asynchronous	ah-SIN-kro-nus	ay-SING-kruh-nus	Starts with 'ay' (like the letter A), stress on SING.
idempotent	eye-DEM-po-tent	eye-dem-POH-tent	Stress on the third syllable: POH.

Written vs. Spoken English

Engineers often write one way on Slack or GitHub, but speak differently in meetings. Here's how to translate.

Proposing architecture

Written (Slack/PR)

I recommend implementing an event-driven architecture leveraging Apache Kafka for asynchronous message processing.

Spoken (Meeting)

“I think we should go with an event-driven setup — Kafka for the message queue, workers to process them asynchronously.”

Discussing failure modes

Written (Slack/PR)

The system should implement circuit-breaker patterns to handle downstream service failures gracefully.

Spoken (Meeting)

“If the downstream service starts failing, we'd use a circuit breaker so we stop hammering it and fail fast instead.”

Estimating scale

Written (Slack/PR)

Anticipated throughput: 10M notifications/day, ~115 per second at peak.

Spoken (Meeting)

“We're looking at about ten million notifications a day — so roughly a hundred and fifteen per second at peak.”

Example Dialogue

YouAlright, let me walk you through the high-level architecture for the notification service. At a high level, we'll have three layers: an ingestion API, a message queue, and a set of delivery workers.

Tech LeadWhy a message queue instead of directly calling the push notification providers?

YouTwo reasons. First, it decouples the ingestion from the delivery, so if a provider is slow, we don't block the API. Second, it gives us natural retry semantics — if a delivery fails, the message stays in the queue.

Senior EngineerWhat queue technology are you thinking? Kafka? RabbitMQ?

YouI'd lean toward Kafka for this use case. We need high throughput and we want to be able to replay events if something goes wrong. Kafka's retention model fits that well.

Tech LeadWhat about the database layer? How do we track which notifications were delivered?

YouI'd suggest a write-optimized store like Cassandra for delivery status. We're looking at millions of writes per day, and Cassandra handles that kind of write-heavy workload really well.

Senior EngineerAnd if a consumer crashes mid-processing?

YouGood question. Kafka handles that with consumer group offsets. If a consumer crashes, another one in the group picks up where it left off. We'd also add dead-letter queues for messages that fail after multiple retries.

Common Questions

How do I explain complex architecture to non-technical stakeholders?

Use analogies and skip the jargon. Instead of 'message queue with consumer groups,' say 'Think of it like a post office — messages come in, get sorted, and multiple delivery workers pick them up and deliver them in parallel.' Focus on the business outcome, not the implementation.

What's the best way to handle disagreements about architecture?

Always focus on trade-offs, not opinions. Say 'Both approaches are valid. Option A gives us better performance but is harder to maintain. Option B is simpler but may not scale past a million users. Which trade-off aligns with our current priorities?'

How do I present a system design in a job interview?

Start with requirements clarification, then outline the high-level design, then dive into components. Use phrases like 'Let me start by clarifying the requirements…' and 'At a high level, the system has three main components…' Practice drawing diagrams while explaining aloud.

Stop Stumbling on Tech Calls

Practice explaining code, architecture, and bugs with an AI coach that understands engineering context.

Start Practicing Now

No credit card required.

More Tech Scenarios

Explaining Architecture Decisions

Technical Interviews

Incident Post-Mortems