SYS ARCHITECTLearning Platform

Phase 1

  • Interview Framework
  • Back-of-the-Envelope Estimation
  • ACID
  • CAP
  • Consistency vs Integrity
  • Idempotency
  • NFR
  • SPOF
  • Stateless vs Stateful
  • SOLID
  • SRP
  • OCP
  • LSP
  • DIP vs LSP
  • Clear Architecture Principles
  • 12-Factor App

    • Phase 2

  • SQL vs NoSQL
  • Normalization vs Denormalization
  • Partition vs Sharding
  • Sharding
  • Partition Tolerance
  • Serializable Transactions
  • MVCC
  • Optimistic vs Pessimistic Locking
  • Row Level Locking
  • Distributed Locks
  • Redis Lock
  • Replication
  • Primary Replica Setup
  • Eventual Consistency
  • Data Consistency
  • Quorum
  • Write Ahead Logs
  • Redo Logs
  • DB Durability
  • Data Recovery
  • Two Phase Commit
  • Saga Pattern
  • Cassandra
  • S3
  • HDFS
  • Timeseries DB

    • Phase 3

  • Caching
  • Cache Eviction Policies
  • Hot Keys
  • Hot Reads and Writes
  • Latency
  • Latency vs Throughput
  • Tail Latency
  • Low Latency Patterns
  • Backpressure
  • Sudden Traffic Spike
  • Buffer Burst

    • Phase 4

  • Replication
  • Consistent Hashing
  • Leader Election
  • Distributed Locking
  • Fault Tolerance
  • Resiliency
  • Raft Consensus
  • Paxos
  • Event Driven Architecture
  • Event Sourcing
  • Outbox Pattern
  • CQRS

    • Phase 5

  • How HTTP Works
  • HTTP vs HTTPS
  • TCP vs UDP
  • TLS
  • Long Polling vs WebSockets
  • Server Sent Events
  • Load Balancer
  • L4 vs L7
  • Load Balancer vs Reverse Proxy vs API Gateway
  • CDN
  • Geo DNS

    • Phase 6

  • JWT
  • OAuth2
  • Opaque vs JWT Token
  • TLS
  • OWASP
  • Secrets Management

    • Phase 7

  • Creating Docker Image
  • Kubernetes ConfigMap
  • Kubernetes Ingress
  • Persistent Volume
  • Prometheus and Grafana

    • Phase 8

  • Monolith vs Microservices
  • API Gateway
  • Unique ID Generator
  • Retry Mechanism
  • Deployment Strategy
  • Rate Limiting

    • Phase 9

  • URL Shortener
  • Chat System
  • News Feed
  • Web Crawler
  • Notifications Design
  • System Design Problems
    • Settings
    Theory

    SQL vs NoSQL: Architectural Decision Framework

    📋 Overview

    The choice between SQL (Relational) and NoSQL (Non-Relational) is a fundamental architectural decision that impacts scalability, consistency, and developer velocity. It is not a binary choice of "better," but a selection based on the specific data access patterns, consistency requirements, and scale of the system.

    🏗️ Core Principles & Characteristics

    • SQL (Relational):
      • Data Model: Rigid schema, tables with rows/columns, strongly typed.
      • Relationships: Enforced via Foreign Keys and complex JOINS.
      • Consistency: ACID (Atomicity, Consistency, Isolation, Durability) compliant.
    • NoSQL (Non-Relational):
      • Data Model: Flexible schema (Key-Value, Document, Graph, Wide-Column).
      • Scaling: Designed for horizontal partitioning (Sharding) out of the box.
      • Consistency: Often BASE (Basically Available, Soft state, Eventual consistency).

    ⚖️ Trade-offs: Pros & Cons

    SQL

    • Pros: Strict data integrity, powerful ad-hoc querying, mature ecosystem.
    • Cons: Horizontal scaling is complex (requires sharding), rigid schema makes rapid changes difficult.

    NoSQL

    • Pros: High write throughput, easy horizontal scaling, handles unstructured data gracefully.
    • Cons: Eventual consistency can lead to data stale-ness, lack of standardized query language, "Joins" must often be handled in application code.

    🌍 Real-World Implementation

    • Financial Systems (SQL): Using PostgreSQL or MySQL for transactions where ACID compliance is non-negotiable (e.g., Ledger, Payments).
    • Social Media Feeds (NoSQL): Using Cassandra or DynamoDB for high-velocity "writes" and feed generation where eventual consistency is acceptable.
    • Content Management (NoSQL): Using MongoDB for flexible document structures that vary by content type.
    • Real-time Analytics (NoSQL): Using Wide-column stores (HBase) for massive time-series data ingestion.

    💡 Interview "Gotchas" & Tips

    • The PACELC Theorem: Go beyond CAP. Explain that even when there is no partition, systems trade off Latency vs. Consistency.
    • "Can SQL Scale?": Mention NewSQL (e.g., CockroachDB, Google Spanner) which provides SQL interfaces with NoSQL-style horizontal scalability.
    • Schema-on-Read vs. Schema-on-Write: NoSQL uses Schema-on-Read (flexible), while SQL uses Schema-on-Write (strict).
    • Normalization vs. Denormalization: SQL optimizes for storage (normalization), while NoSQL optimizes for read speed (denormalization).

    📐 Suggested Architecture Primitives

    • RDBMS: PostgreSQL, MySQL, SQL Server for relational needs.
    • Document Store: MongoDB, CouchDB for flexible JSON-like data.
    • Wide-Column: Cassandra, ScyllaDB for high-write, large-scale data.
    • In-Memory/KV: Redis, Memcached for low-latency caching.
    • Graph: Neo4j for highly interconnected data (fraud detection, social graphs).
    Canvas