Clarify first: volumes, geography, scale, security, consistency and accuracy expectations.
Narrow the scope: who the users are, devices, environment.
List the high-level APIs (HTTP method + parameters) before drawing boxes.
Then the building blocks: client, DNS, API gateway, services, DB.
Gaps to fix
No back-of-envelope math. Turn volumes into QPS, storage and bandwidth. The numbers should drive the decisions (see Estimation).
No "where does this break" step. After the boxes, say: here is the bottleneck at 10x, and here is what I would do.
DB choice by a myth. "Relational for consistency, NoSQL for eventual" is wrong. See Choosing a database.
A 45-minute shape
Requirements and scope (functional + non-functional).
Estimation (QPS, storage, read:write ratio).
APIs and data model.
High-level design.
Deep dive on the 1-2 hard parts.
Bottlenecks, failure modes, trade-offs.
Requirements: functional vs non-functional
Functional is what users can do. These are verbs: send a message, upload media, see delivery status.
Non-functional is how well, ideally with a number or a guarantee: p99 under 500 ms, no loss after the ack, same order for everyone, 30-day retention, data residency.
Always list the guarantees (no loss, ordering, consistency) out loud. They are what drive the design.
State your own assumptions with numbers instead of waiting for the interviewer to supply them.
Summary: say it in the interview
Say "unless the numbers say otherwise" before picking exotic tech. Most "scale" problems are smaller than they sound.