System Design Prerequisites: Level 3 & 4

Welcome back to the system design prerequisites series! In Part 1, we covered the fundamentals from computer architecture to networking protocols. Now we're diving deeper into the advanced concepts that form the backbone of modern distributed systems. This part focuses on data management, scalability patterns, and security considerations that every system designer should understand.

Contents

Level 3

Level 3 introduces the core building blocks of scalable systems. Here we explore data storage strategies, caching mechanisms, and communication patterns that enable applications to handle millions of users. These concepts bridge the gap between basic networking knowledge and advanced architectural patterns. Understanding these fundamentals is crucial before diving into complex distributed system designs.

Databases: RDBMS vs NoSQL

Relational databases (RDBMS) like MySQL and PostgreSQL provide ACID properties , structured schemas, and complex querying capabilities through SQL. Now what is ACID?

• Atomicity: All operations in a transaction must either complete successfully or fail entirely with a rollback
• Consistency: A transaction can only bring the database from one valid state to another valid state
• Isolation: Concurrent transactions must not affect each other's execution
• Durability: Once a transaction is committed, it will remain committed even in case of system failure

They excel at maintaining data consistency and handling complex relationships. NoSQL databases like MongoDB, Cassandra, and Redis offer flexibility, horizontal scalability, and specialized data models (document, key-value, graph, column-family). The choice depends on your consistency requirements, scalability needs, and data structure. RDBMS for complex transactions and strict consistency; NoSQL for rapid scaling and flexible schemas.

Replication, Sharding & Partitioning

Replication creates copies of data across multiple servers for availability and read performance. Master-slave replication handles writes on master, reads on slaves. Master-master allows writes on multiple nodes but requires conflict resolution. Sharding distributes data across multiple databases based on a shard key (horizontal partitioning). Vertical partitioning splits tables by columns. Hash-based sharding uses hash functions for even distribution. Range-based sharding groups related data together. Directory-based sharding uses a lookup service to locate data.

Caching Strategies

Caching stores frequently accessed data in fast storage to reduce latency and database load. Browser cache stores static assets locally. CDN cache distributes content globally. Application cache (Redis, Memcached) stores computed results. Database cache speeds up query results. Cache-aside (lazy loading) loads data on cache miss. Write-through updates cache and database simultaneously. Write-behind (write-back) updates cache immediately, database asynchronously. Cache eviction policies include LRU (Least Recently Used), LFU (Least Frequently Used), FIFO (First In First Out), and TTL (Time To Live) for automatic expiration.

CAP Theorem

CAP Theorem states that distributed systems can only guarantee two of three properties: Consistency (all nodes see the same data simultaneously), Availability (system remains operational), and Partition tolerance (system continues despite network failures). CP systems (like MongoDB) prioritize consistency and partition tolerance, sacrificing availability during network issues. AP systems (like Cassandra) maintain availability and partition tolerance but may serve stale data. CA systems work only in single-node scenarios since network partitions are inevitable in distributed systems.

Message Queues & Pub-Sub

Message queues enable asynchronous communication between services, improving system resilience and scalability. Point-to-point queues deliver messages to single consumers (RabbitMQ, Amazon SQS). Publish-Subscribe patterns broadcast messages to multiple subscribers (Apache Kafka, Redis Pub/Sub). Use cases include order processing, email notifications, log aggregation, and event-driven architectures. Benefits include decoupling services, handling traffic spikes, ensuring message delivery, and enabling microservices communication. Message brokers provide durability, routing, and delivery guarantees.

Monolith vs Microservices

Monolithic architecture deploys entire application as single unit. Benefits: simple development, testing, and deployment; better performance due to in-process calls; easier debugging. Drawbacks: technology lock-in, scaling entire app for one component, single point of failure. Microservices architecture splits application into independent services. Benefits: technology diversity, independent scaling and deployment, fault isolation, team autonomy. Drawbacks: network complexity, distributed system challenges, operational overhead, eventual consistency issues. Choose monolith for simple applications and small teams; microservices for complex, large-scale systems with multiple teams.

Level 4

Level 4 covers advanced system design patterns and security considerations essential for production systems. These concepts focus on performance optimization, security, and operational excellence. Topics include global content distribution, traffic management, and robust authentication mechanisms. Mastering these areas enables you to design systems that can handle enterprise-scale requirements while maintaining security and performance standards.

Content Delivery Networks (CDN)

CDNs distribute content across geographically dispersed servers to reduce latency and improve user experience. Edge servers cache static assets (images, CSS, JavaScript) closer to users. Benefits include faster load times, reduced origin server load, improved availability, and DDoS protection. CDNs use techniques like geographic routing, caching policies, and content optimization. Popular CDNs include CloudFlare, Amazon CloudFront, and Akamai. CDNs are essential for global applications, media streaming, and e-commerce platforms where performance directly impacts user engagement and revenue.

Rate Limiting & Throttling

Rate limiting controls the number of requests a client can make within a time window, preventing abuse and ensuring fair resource usage. Common algorithms include Token Bucket (allows bursts), Leaky Bucket (smooth rate), Fixed Window (simple but allows spikes), and Sliding Window (more accurate). Throttling gradually reduces service quality under load. Implementation can be at API gateway, application level, or infrastructure level. Rate limiting protects against DDoS attacks, ensures SLA compliance, and prevents resource exhaustion. Consider user experience when implementing - provide clear error messages and retry guidance.

Authentication and Authorization

Authentication (AuthN) verifies user identity; Authorization (AuthZ) determines access permissions. Session-based authentication stores user state on server, uses cookies for client identification. Stateful but simple to implement and revoke. JWT (JSON Web Tokens) are stateless, self-contained tokens with encoded user information and expiration. Scalable but harder to revoke. OAuth 2.0 enables third-party authentication (Google, Facebook login) without sharing credentials. Provides scoped access and refresh tokens. Choose session-based for simple applications, JWT for distributed systems, OAuth for third-party integrations. Always use HTTPS and implement proper token storage and rotation.