Technical Communication & Architecture Reviews

Backend engineers are frequently asked to present system designs, explain architectural decisions, and defend trade-offs. These skills are tested explicitly in system design rounds and implicitly in every technical conversation.

Explaining Architecture to Non-Technical Stakeholders

The ability to adjust your communication level is a strong L5+ signal.

The Three-Layer Explanation

Audience	Level	Example: Explaining Database Sharding
Executive	Business impact	"We're splitting our database into smaller pieces so the system can handle 10x more users without slowing down. This costs $X more per month but prevents the outages we saw last quarter."
Product Manager	Feature implications	"Sharding means some queries that work across all users (like global leaderboards) become more complex. We need to discuss which cross-shard features to prioritize."
Engineering	Technical details	"We're implementing hash-based sharding on user_id with a consistent hashing ring. Cross-shard queries will use scatter-gather through an aggregation layer."

Drawing System Diagrams

In whiteboard/virtual interviews, how you draw matters as much as what you draw.

Diagram Best Practices

1. Start with the user — Always draw the client/user first on the left side
2. Left to right flow — Requests flow left → right (client → load balancer → API → DB)
3. Label everything — Every box needs a name, every arrow needs a description
4. Separate read and write paths — Show them as distinct flows when they differ
5. Add numbers — Include QPS estimates or data sizes on arrows

Standard Backend Architecture Diagram

Client → CDN → Load Balancer → API Servers → Cache (Redis)
                                    ↓              ↓
                              Message Queue    Database (Primary)
                                    ↓              ↓
                              Workers         Read Replicas
                                    ↓
                              Blob Storage

Sequence Diagrams for APIs

When explaining request flows, use a simplified sequence diagram:

Client          API Gateway       Auth Service      Payment Service      Database
  |                  |                 |                   |                 |
  |--- POST /pay --->|                 |                   |                 |
  |                  |-- verify JWT -->|                   |                 |
  |                  |<-- valid -------|                   |                 |
  |                  |--- process payment --------------->|                 |
  |                  |                 |                   |-- BEGIN TXN --->|
  |                  |                 |                   |-- INSERT ------>|
  |                  |                 |                   |-- COMMIT ------>|
  |                  |                 |                   |<-- OK ----------|
  |                  |<-------------- payment_id ---------|                 |
  |<-- 201 Created --|                 |                   |                 |

Trade-Off Discussions

Backend interviewers love trade-off questions. They reveal whether you truly understand systems or just memorize patterns.

Common Trade-Off Questions

"SQL vs. NoSQL for this use case?"

Factor	Lean SQL	Lean NoSQL
Data relationships	Complex joins needed	Denormalized, embedded documents
Consistency needs	ACID transactions required	Eventual consistency acceptable
Query patterns	Complex, ad-hoc queries	Known access patterns, key-based
Scale	Moderate (single-region typical)	Massive horizontal scale needed
Schema	Stable, well-defined	Evolving, schema-flexible

"Monolith vs. Microservices?"

Don't default to "microservices are better." Strong answers acknowledge:

• Monolith is simpler to deploy, debug, and test
• Microservices add network latency, operational complexity, and debugging difficulty
• Start with a modular monolith, extract services when team/scale demands it
• Conway's Law: architecture follows team structure

"Synchronous vs. Asynchronous communication?"

Factor	Synchronous (REST/gRPC)	Asynchronous (Message Queue)
Latency	Immediate response	Eventual processing
Coupling	Tight (caller waits)	Loose (fire-and-forget)
Reliability	Caller handles failure	Queue provides durability
Debugging	Simpler request tracing	Harder to trace message flow
Use case	User-facing requests	Background processing, event-driven

Handling "I Don't Know" Gracefully

Every candidate hits a knowledge gap. How you handle it matters:

Bad: "I'm not sure about that." (End of discussion)

Good: "I haven't worked with Cassandra directly, but based on my understanding of column-family stores, I'd expect the access pattern to be optimized for writes with eventual consistency. For this use case, I'd want to understand the read patterns before committing to it. Let me reason through the trade-offs..."

Key principle: Demonstrate your problem-solving process even when you don't know the specific technology. Interviewers evaluate how you reason, not whether you've memorized every system.

Asking Clarifying Questions

The first 5 minutes of a system design round should be clarifying questions. Backend-specific questions to ask:

• "What's the expected QPS? Read-to-write ratio?"
• "What consistency guarantees do we need?"
• "What's the acceptable latency? p50 vs. p99?"
• "Is this a single-region or multi-region deployment?"
• "What's the data retention policy?"
• "Do we need real-time processing or is batch acceptable?"
• "What's the team size maintaining this system?"

Next: Salary negotiation strategies and career growth paths for backend engineers. :::