System Design Prerequisites You Should Always Consider
The Checklist I Wish I Had Before Designing My First Scalable System
Designing scalable systems isn’t just about knowing the tools it’s about asking the right questions upfront. Before you look into architecture diagrams, here’s a checklist every developer should walk through.
1. Understand the Goal
Before writing a single line of code or diagramming a system, ask:
What exactly are you building? (e.g., a social media platform)
Who’s using it? (teenagers, professionals, businesses)
Main use case: (sharing photos, professional networking, online payments)
Without a clear goal, you may end up overengineering, solving the wrong problem, or missing critical user expectations.
A system for internal use by employees has vastly different needs than one for millions of external users.
2. Traffic Pattern: Read-Heavy vs Write-Heavy
This helps you determine where to focus your optimization efforts.
Systems like Netflix prioritize fast content delivery. Caching, CDN, and read replicas are essential.
Apps like WhatsApp focus on handling huge volumes of incoming data reliably, using queues and write buffers.
Designing a read-heavy system with write-heavy optimizations leads to wasted resources and poor performance. This is one of the most foundational choices in backend architecture.
3. Consistency vs Availability
In distributed systems, you often can’t have both perfect consistency and high availability (CAP theorem).
Strict consistency: Needed when any mismatch is unacceptable (e.g., showing $500 when your bank balance is actually $300 is a big problem).
Eventual consistency: Perfectly fine when real-time precision isn’t required (e.g., social feeds showing a post a few seconds late).
Misjudging this can lead to system unreliability or over-complexity. Choose based on business risk.
4. Latency Requirements
Do users expect instant results, or can they wait?
Real-time (low latency): Critical for gaming, live streaming, or payment systems. Use caching or precomputed data.
e.g Think of Zoom. A 1-second delay ruins the experience or a Google Pay transactions.
Async (higher latency is okay): Tasks like email delivery or report generation.
e.g Email confirmations can take a few seconds without hurting UX, analytics reports generation.
This directly influences your use of technologies like message queues, caching, or background workers. Over-optimizing for real-time needs can make your system costly and fragile.
5. Expected Scale
Think long-term. You might start with 100 users - but will it still work with 10 million?
Initial design (MVP) can be simple but should easily scale.
Google Docs: Started small, now supports millions of users editing simultaneously.
Uber: Handles thousands of ride requests per minute with horizontal scaling and stateless services.
Systems often fail not because of bugs, but because they weren’t designed to handle growth. Google Docs scaled from a basic collaborative editor to a complex real-time system. If you don’t design with scalability in mind, rewrites become painful and expensive.
6. Access Patterns
Identify what data is accessed most frequently or in which pattern.
If you choose the wrong pattern (e.g., hitting DB for every search), you risk slow performance, high cost, and poor UX. Patterns should align with actual user interaction and scale expectations.
7. Data Growth & Partitioning
Data will grow. Will your system crash when it does?
YouTube Comments → Sharded by Video ID
Each video can have millions of comments, but comments under different videos are unrelated. So YouTube shards the data byvideo_idto avoid one giant table and to make reads/writes faster.Twitter Tweets → Sharded by User ID + Time
Tweets are partitioned byuser_idand sometimes by time buckets. This allows fast access to a user's timeline and prevents hot partitions when a user tweets frequently.Bank Transactions → Partitioned by Account Number + Date
To retrieve and archive transactions efficiently, banks shard data by account number and archive old records beyond 6–12 months to cold storage (e.g., tape drives or long-term S3).Google Drive / Gmail → Archive Cold Data
Old files or emails are rarely accessed but take up space. These are moved to low-cost, long-term storage, improving DB performance and cutting storage costs.
As your app scales, unpartitioned data becomes a bottleneck. Without planning for growth, even a basic query like “get all orders for user X” can slow down, affecting everyone.
8. Failure Handling
Things break. Servers crash. Networks fail. How does your system cope?
You don’t want users facing 500 errors every time something small fails. Proper retries, fallbacks, and circuit breakers ensure graceful degradation and better user trust.
9. Security & Auth
If your app is public-facing or handles user data, you must think about:
Who can access what?
How do you prevent abuse?
Security is often treated as an afterthought — until something goes wrong. Implementing OAuth, rate limiting, and CAPTCHA from day one protects your system and your users.
10. Do You Need to Build It All?
You don’t need to reinvent the wheel. Use existing, battle-tested services.
Can you use a 3rd party for auth, payments, media, etc.?
Offload non-core features to SaaS or APIs
Building everything in-house is tempting but inefficient. Offloading non-core parts lets you focus on your unique value. If Uber built its own media service or SMS gateway from scratch, it would have slowed their growth drastically.
These aren’t hard rules - but they’ll save you from hard rewrites. Think of them as your system design compass.
And once your system is built, don’t forget to think about observability (logs, metrics, alerts), deployment strategy (CI/CD, rollback), data backups, cost optimization, and team ownership.
Because building is just the beginning - running it well is where the real game begins. Will share that in some other article.