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

    12-Factor App Principles

    📋 Overview

    The 12-Factor App is a methodology for building software-as-a-service (SaaS) applications that are portable, resilient, and scalable. It solves the core problems of "works on my machine" syndrome and scaling bottlenecks by enforcing strict separation between code, configuration, and state.

    🏗️ Core Principles & Characteristics

    • Codebase: One codebase tracked in version control, many deploys.
    • Dependencies: Explicitly declare and isolate dependencies (no reliance on system-wide packages).
    • Config: Store configuration in the environment (variables), never in the code.
    • Backing Services: Treat databases, caches, and queues as attached resources.
    • Build, Release, Run: Strictly separate these stages; releases are immutable.
    • Processes: Execute the app as one or more stateless, share-nothing processes.
    • Port Binding: Export services via port binding (self-contained).
    • Concurrency: Scale out via the process model (horizontal scaling).
    • Disposability: Maximize robustness with fast startup and graceful shutdown.
    • Dev/Prod Parity: Keep development, staging, and production as similar as possible.
    • Logs: Treat logs as event streams, not managed files.
    • Admin Processes: Run management/admin tasks as one-off processes.

    ⚖️ Trade-offs: Pros & Cons

    Feature / ApproachAdvantages (Pros)Disadvantages (Cons)
    StatelessnessSeamless horizontal scaling and high fault tolerance.Requires external state management (e.g., Redis), increasing latency for state access.
    Environment ConfigHigh security (no secrets in repo) and easy environment switching.Can lead to "config sprawl" if not managed by a central orchestrator.
    Port BindingRemoves dependency on external web servers like Apache/Nginx.Requires the application to handle its own networking stack complexities.

    🌍 Real-World Implementation

    • Tech Stack: Heroku (where it originated), Kubernetes, Docker, AWS Lambda.
    • Use Case: Modern microservices architecture where services must be deployed and scaled independently across cloud providers.

    💡 Interview "Gotchas" & Tips

    • The "Stateless" Myth: Remember that while the app is stateless, the system is not. State must be pushed to backing services (DBs/Caches).
    • Parity Gap: Be prepared to discuss how Docker helps achieve Dev/Prod parity but doesn't solve differences in backing service scale (e.g., local SQLite vs. prod RDS).

    📐 Suggested Architecture Primitives

    • Client, Gateway, Server, Service, SQL, NoSQL, Cache, MQ, Cloud, Auth
    Canvas