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

    Monolithic vs. Microservices

    📋 Overview

    The debate between Monolithic and Microservices architectures is essentially a trade-off between simplicity and scalability. A Monolith is a single, self-contained unit where all business logic lives in one codebase, while Microservices distribute that logic into small, independent services that communicate over a network.

    🏗️ Core Principles & Characteristics

    Monolithic

    • Unified Unit: Everything from UI to DB access is bundled into one artifact (WAR, JAR, Executable).
    • In-Process Communication: Modules talk to each other via simple function calls (ultra-fast).
    • Shared Data: One massive database schema for the entire application.

    Microservices

    • Decoupling: Services are organized around business capabilities (e.g., "Cart Service", "Inventory Service").
    • Database-per-Service: Each service owns its data to prevent "hidden coupling" at the DB layer.
    • Inter-Process Communication (IPC): Services talk via REST, gRPC, or Message Queues (Kafka/RabbitMQ).

    ⚖️ Trade-offs: Pros & Cons

    Monolithic

    • Pros: Easy to deploy; simpler to test; lower initial overhead; zero network latency between modules.
    • Cons: "Dependency Hell"—one bad line of code can crash the whole app; scaling requires duplicating the entire app, even if only one module is busy; slow build/deploy times as the app grows.

    Microservices

    • Pros: Independent scaling (scale only the "Search" service); fault isolation; technology flexibility (Polyglot); faster deployments for individual teams.
    • Cons: "Distributed System Complexity"—handling network failures, retries, and data consistency (Sagas) is extremely hard; significant operational overhead (Service Mesh, K8s, Distributed Tracing).

    🌍 Real-World Implementation

    • Early-Stage Startups: Almost always start with a Monolith (or a "Modular Monolith") to find product-market fit without the overhead of microservices.
    • Amazon/Netflix: Famous for their transition from giant monoliths to thousands of microservices to support their massive scale and thousands of developers.
    • The "Citadel" Pattern: Keeping the core legacy app as a monolith but building all new features as microservices that talk back to the core.

    💡 Interview "Gotchas" & Tips

    • Don't "Silver Bullet" Microservices: Never suggest microservices for a small team of 3 people. The "Microservices Tax" (the operational overhead) will kill the startup.
    • Distributed Transactions: If asked how to maintain consistency, mention the Saga Pattern or Two-Phase Commit (2PC), but emphasize that event-driven Eventual Consistency is usually preferred.
    • The "Distributed Monolith" Trap: Beware of microservices that are so tightly coupled that they must be deployed together. This is the worst of both worlds.

    📐 Suggested Architecture Primitives

    • API Gateway: The single entry point for clients to talk to multiple microservices.
    • Service Discovery (Consul/Eureka): How services find each other's dynamic IP addresses.
    • Sidecar Proxy (Envoy): To handle retries, timeouts, and mTLS between services.
    • Database Sharding: Often used in monoliths as a middle ground before moving to microservices.
    Canvas