Required Foundational Knowledge - Prerequisites & Learning Path | OneNoughtOne

0/319

System Design (HLD)Prerequisites & Learning Path

Prerequisites & Learning Path

LevelBeginner

Duration50 mins

TopicPrerequisites & Learning Path

1 / 4

Required Foundational Knowledge

Before You Begin: Setting the Foundation

System Design is not a subject you can learn in isolation. It sits at the apex of software engineering knowledge, synthesizing concepts from programming, networking, databases, distributed systems, and operational understanding into coherent architectural decisions. Before you embark on this journey, it's essential to understand what foundational knowledge you'll need—and why each piece matters.

The good news: You don't need to be an expert in every area before starting. But you do need a working familiarity with certain core concepts. This page will help you honestly assess where you stand and identify any gaps worth addressing before diving deeper.

What You Will Learn

By the end of this page, you'll have a comprehensive understanding of the foundational knowledge areas required for System Design mastery. You'll be able to assess your current proficiency, identify knowledge gaps, and understand why each prerequisite is essential for making sound architectural decisions.

The Building Blocks Metaphor

Think of System Design as constructing a skyscraper. You cannot design a 100-story building without understanding the properties of steel, concrete, and glass. You cannot plan for earthquakes without grasping the fundamentals of structural engineering. Similarly, you cannot design distributed systems handling millions of users without understanding how networks transmit data, how databases store and retrieve information, or how operating systems manage resources.

Each prerequisite area contributes specific capabilities:

Foundational Knowledge Areas and Their Role in System Design
Knowledge Area	What It Enables	Without It...
Programming Fundamentals	Reasoning about code complexity, data structures, algorithm selection	You can't evaluate whether a design is implementable or efficient
Networking Basics	Understanding latency, bandwidth, protocols, request/response patterns	You can't reason about communication overhead or failure modes
Database Concepts	Choosing storage solutions, understanding consistency models, query optimization	You can't design data layers that scale and perform
Operating Systems	Process management, memory, I/O, concurrency primitives	You can't understand resource constraints or bottlenecks
API Design	Defining service interfaces, contracts, versioning	You can't design services that communicate cleanly
Basic Security	Authentication, authorization, encryption fundamentals	Your designs will have fundamental security flaws

Depth vs Breadth

System Design requires breadth across many areas rather than extreme depth in one. You don't need to implement a TCP stack from scratch, but you should understand what TCP guarantees and when those guarantees affect your design decisions. The goal is working fluency, not academic mastery.

Programming Fundamentals

At its core, System Design involves making decisions about code—even if you never write a single line during a design session. You must be able to reason about:

Data Structures and Algorithms (DSA)

Understanding time and space complexity is non-negotiable. When you propose using a hash map for O(1) lookups versus a sorted array requiring O(log n) binary search, you need to understand the implications. When someone asks, "What happens when we have 10 million records?" you should be able to reason about algorithmic scaling.

Key concepts you should be comfortable with:

DSA Prerequisites

•Big O Notation — Analyzing time complexity (O(1), O(log n), O(n), O(n log n), O(n²)) and space complexity. Understanding amortized analysis.
•Core Data Structures — Arrays, linked lists, hash tables, trees (BST, balanced trees), heaps, graphs. Knowing when to use each.
•Common Algorithms — Sorting, searching, graph traversal (BFS, DFS), basic dynamic programming concepts.
•Trade-off Reasoning — Understanding that choosing a data structure involves trade-offs between read speed, write speed, memory usage, and ordering guarantees.

Object-Oriented and Functional Concepts

You should understand encapsulation, abstraction, interfaces, and polymorphism—not because every system uses OOP, but because these concepts help you reason about modularity, separation of concerns, and clean boundaries between components.

Functional concepts like immutability, pure functions, and avoiding shared mutable state are increasingly important in distributed systems where reasoning about side effects is critical.

Concurrency and Parallelism

Modern systems execute many operations simultaneously. You need to understand:

•Threads vs Processes — What they share, how they communicate, context switching costs
•Race Conditions — How they occur, why they're dangerous, and how to prevent them
•Locks and Synchronization — Mutexes, semaphores, deadlocks, and why lock-free designs are attractive
•Asynchronous Programming — Async/await patterns, event loops, non-blocking I/O

Self-Assessment: Programming

Can you explain why a hash table provides O(1) average lookup? Can you describe what happens when two threads try to update the same variable without synchronization? If these questions feel unclear, consider strengthening your programming fundamentals before diving deep into distributed systems.

Networking Basics

Every distributed system is, at its foundation, a network of machines communicating over network protocols. Without understanding networking, you cannot reason about latency, failure modes, or the fundamental challenges that make distributed systems hard.

The OSI and TCP/IP Models

You don't need to memorize all seven OSI layers, but you should understand the conceptual separation between:

Physical/Link layers — How bits travel (Ethernet, WiFi)
Network layer (IP) — Addressing and routing packets across networks
Transport layer (TCP/UDP) — Reliable vs unreliable delivery, ports, connections
Application layer (HTTP, DNS, etc.) — Protocols your services actually speak

Essential Networking Concepts for System Design
Concept	Why It Matters
IP Addresses and DNS	How machines find each other; DNS as a critical dependency with caching implications
TCP vs UDP	Reliability vs speed trade-off; when to use each (HTTP typically uses TCP; video streaming often uses UDP)
HTTP/HTTPS	The dominant application protocol; methods (GET, POST, PUT, DELETE), status codes, headers, request/response cycle
Latency vs Bandwidth	Latency = time to first byte; bandwidth = capacity. A high-bandwidth link with high latency still feels slow for small requests.
Round Trip Time (RTT)	How network distance affects response times; why multi-region deployments reduce latency
Load Balancers	L4 (transport) vs L7 (application) load balancing; distributing traffic across servers
Firewalls and NAT	Network boundaries, security zones, address translation affecting connectivity

HTTP Deep Dive

Since most modern systems communicate via HTTP (or its successor protocols like HTTP/2 and HTTP/3), you should understand:

Request/Response Anatomy — Headers, body, methods, status codes
Statelessness — HTTP is stateless by default; how cookies and tokens provide session continuity
Connection Keep-Alive — Reusing TCP connections to reduce handshake overhead
HTTP/2 and HTTP/3 — Multiplexing, header compression, and why they matter for performance
REST Principles — Resources, representations, statelessness, cacheability

Latency Numbers Every Engineer Should Know

Memory reference: ~100 ns. SSD read: ~100 μs. Network round trip within datacenter: ~0.5 ms. Network round trip cross-continent: ~100 ms. These orders of magnitude dramatically affect design decisions. An operation that's acceptable at memory speed becomes unacceptable at network speed when called in a loop.

Database Concepts

Data is the lifeblood of any system. How you store, retrieve, and manage data determines scalability, reliability, and performance. You need a solid foundation in database concepts before designing data-intensive systems.

Relational Databases (RDBMS)

Understanding relational databases remains essential, even as NoSQL options proliferate:

Relational Database Prerequisites

•SQL Fundamentals — SELECT, JOIN, GROUP BY, aggregations. Understanding query execution and what makes queries slow.
•Schema Design — Tables, columns, primary keys, foreign keys. Normalization levels and when to denormalize.
•Indexes — B-tree indexes, composite indexes, covering indexes. How indexes accelerate reads but slow writes.
•ACID Properties — Atomicity, Consistency, Isolation, Durability. What guarantees transactions provide.
•Isolation Levels — Read uncommitted, read committed, repeatable read, serializable. Trade-offs between consistency and performance.
•Transactions — BEGIN, COMMIT, ROLLBACK. How transactions interact with locking.

NoSQL and Alternative Data Stores

Modern systems often use multiple data store types. You should understand conceptually:

Key-Value Stores (Redis, DynamoDB) — Simple, fast lookup by key; limited querying capability
Document Databases (MongoDB, Couchbase) — Schema flexibility, nested documents, JSON-like storage
Column-Family Stores (Cassandra, HBase) — Wide columns, designed for write-heavy workloads
Graph Databases (Neo4j) — Optimized for relationship-heavy queries
Time-Series Databases (InfluxDB, TimescaleDB) — Optimized for temporal data and aggregations

When each makes sense is more important than knowing every feature.

RDBMS Strengths

•Strong consistency guarantees
•Complex query support (JOINs, aggregations)
•Mature tooling and expertise availability
•ACID transactions across multiple operations
•Schema enforcement prevents data corruption

NoSQL Strengths

•Horizontal scalability
•Schema flexibility for evolving data
•Optimized for specific access patterns
•Often higher write throughput
•Designed for distributed deployment

The Right Tool for the Job

Don't fall into the trap of thinking NoSQL replaces RDBMS. Most mature systems use both—relational databases for core transactional data requiring strong consistency, NoSQL stores for caching, session management, or specific use cases like activity feeds.

Operating Systems Fundamentals

System Design ultimately involves running software on machines. Understanding how operating systems manage resources helps you reason about bottlenecks, scaling limits, and operational constraints.

Process and Memory Management

You should understand the fundamental concepts:

•Processes vs Threads — Processes have separate memory spaces; threads share memory within a process. Implications for isolation and communication.
•Context Switching — The cost of switching between processes/threads. Why limiting concurrency sometimes improves performance.
•Virtual Memory — How OS provides each process an illusion of private memory. Swapping and thrashing.
•Memory Allocation — Heap vs stack. Garbage collection in managed languages. Memory leaks.

I/O and Disk

Blocking vs Non-Blocking I/O — How asynchronous I/O allows a single thread to handle many connections
Disk I/O Patterns — Sequential vs random reads/writes. Why SSDs change the game. How databases optimize I/O.
File Systems — Basic understanding of how files are organized, journaling, and durability guarantees

Resource Limits

Every process operates within limits: file descriptors, memory, CPU time, network sockets. Understanding these limits helps you anticipate where systems will break under load.

Common Resource Limits and Their Impact
Resource	Typical Limit	System Design Impact
File Descriptors	1024-65536 per process	Limits concurrent connections per server; requires tuning for high-concurrency services
Memory	Physical RAM + swap	Determines how much data can be cached, how many connections buffered
CPU Cores	Physical cores available	Limits parallelism; more threads than cores causes context switching overhead
Network Bandwidth	1 Gbps - 100 Gbps typical	Caps throughput regardless of how fast your code runs
Disk IOPS	Hundreds (HDD) to millions (NVMe)	Dramatically affects database and storage system performance

Don't Ignore the Metal

Cloud abstractions make it easy to forget that containers and VMs run on physical hardware with real constraints. Understanding OS fundamentals helps you debug mysterious performance issues and right-size resources.

API Design Principles

In System Design, services communicate through APIs. Understanding how to design, version, and evolve APIs is fundamental to building maintainable distributed systems.

REST Fundamentals

REST (Representational State Transfer) dominates web API design. Key principles include:

•Resources and URIs — Everything is a resource identified by a URI. /users/123 represents user 123.
•HTTP Methods — GET (read), POST (create), PUT/PATCH (update), DELETE (remove). Idempotency expectations.
•Statelessness — Each request contains all information needed; server doesn't store session state.
•Status Codes — 2xx success, 3xx redirection, 4xx client error, 5xx server error. Using them correctly.
•HATEOAS — Hypermedia as the engine of application state. Less commonly implemented but conceptually important.

Beyond REST

While REST is dominant, you should be aware of alternatives:

GraphQL — Client specifies exactly what data it needs; reduces over-fetching and under-fetching. Adds complexity.
gRPC — Binary protocol using Protocol Buffers; efficient for microservices communication. Steeper learning curve.
WebSockets — Full-duplex communication; essential for real-time features like chat or live updates.
Webhooks — Server pushes events to clients; inverts the typical polling pattern.

API Versioning and Evolution

APIs change over time. Understanding versioning strategies and backward compatibility is crucial:

URI versioning (/v1/users, /v2/users)
Header versioning (Accept: application/vnd.api+json;version=2)
Deprecation policies and sunset dates
Additive changes vs breaking changes

APIs Are Contracts

An API is a contract between services. Breaking that contract breaks consumers. System Design must account for how APIs evolve, how versions coexist, and how to migrate consumers gracefully.

Security Basics

Security cannot be an afterthought in System Design. Every architectural decision has security implications. You need a baseline understanding of security principles to avoid designing systems with fundamental vulnerabilities.

Authentication vs Authorization

These terms are often confused but represent distinct concepts:

Authentication (AuthN): Verifying who you are. Proving identity via passwords, tokens, biometrics.
Authorization (AuthZ): Verifying what you can do. After confirming identity, checking permissions.

Common Authentication Mechanisms:

•Session-based — Server stores session; client sends session ID cookie. Stateful on server side.
•Token-based (JWT) — Stateless tokens containing claims; server validates signature without storage.
•OAuth 2.0 / OIDC — Delegated authorization; allowing third-party access without sharing credentials.
•API Keys — Simple but limited; good for service-to-service communication with known clients.
•mTLS (Mutual TLS) — Both client and server present certificates; strong service-to-service authentication.

Encryption Fundamentals

Encryption at Rest — Data encrypted when stored (disk encryption, database encryption)
Encryption in Transit — Data encrypted during transmission (TLS/HTTPS)
Symmetric vs Asymmetric — Shared key (AES) vs public/private key pairs (RSA)
Hashing — One-way transformation for password storage (bcrypt, Argon2)

Common Security Considerations in System Design:

Security Considerations by System Component
Component	Security Considerations
API Gateway	Rate limiting, input validation, authentication, TLS termination
Database	Access control, encryption at rest, query parameterization (SQL injection prevention)
Network	Firewalls, VPCs, private subnets, encrypted inter-service communication
Secrets Management	Never hardcode credentials; use vaults (HashiCorp Vault, AWS Secrets Manager)
Logging	Careful not to log sensitive data (PII, tokens, passwords)

Security Is Not Optional

A beautiful, scalable system with security flaws is a liability, not an asset. In interviews and real-world designs, explicitly addressing authentication, authorization, and data protection demonstrates maturity and completeness.

Assessing Your Readiness

Now that we've surveyed the foundational knowledge areas, let's assess your readiness honestly. Use this checklist to identify areas that may need reinforcement:

Readiness Self-Assessment

•Programming: I can analyze the time complexity of nested loops and recursive functions. I understand when to use a hash map vs a tree.
•Networking: I can explain what happens when I type a URL in a browser (DNS, TCP, HTTP flow). I understand latency vs bandwidth.
•Databases: I can write SQL queries with JOINs. I understand what an index does and why transactions exist.
•Operating Systems: I understand the difference between processes and threads. I know why memory or CPU might become bottlenecks.
•APIs: I can design a REST API for a simple resource. I understand HTTP methods and status codes.
•Security: I can explain authentication vs authorization. I understand why HTTPS matters and how tokens work.

You're Ready If...

You checked most boxes with confidence. Some gaps are fine—you'll fill them as you progress through this curriculum. Having working familiarity is enough to start.

Consider Reinforcement If...

Multiple areas feel completely unfamiliar. Consider spending time on foundational courses first. Diving into System Design without prerequisites leads to confusion and surface-level understanding.

Summary: Laying the Foundation

We've covered the essential foundational knowledge areas required for System Design mastery. Let's consolidate the key takeaways:

Key Takeaways

•System Design synthesizes many disciplines — Programming, networking, databases, OS, APIs, and security all contribute to architectural decisions.
•Breadth matters more than extreme depth — Working familiarity across areas is more valuable than expertise in just one.
•Programming fundamentals are non-negotiable — DSA and concurrency understanding are essential for reasoning about system behavior.
•Networking knowledge explains distributed challenges — Latency, failure modes, and protocols underpin all distributed systems.
•Database understanding determines data layer success — Knowing when to use RDBMS vs NoSQL and how to optimize is crucial.
•Security must be considered from the start — Authentication, authorization, and data protection are integral to sound architecture.

What's next:

Now that we've established the foundational knowledge requirements, the next page explores how this curriculum is structured. Understanding the learning path ahead will help you navigate the material efficiently and build knowledge systematically.

Page Complete

You now understand the foundational knowledge areas required for System Design mastery. Honestly assess your current proficiency, address gaps where needed, and prepare for the structured journey through this comprehensive curriculum.