J
Volume
System Design
28 notes·16h to read
Other
28- Networking EssentialsThe networking concepts that actually show up in system design interviews — OSI layers, TCP vs UDP, HTTP/gRPC/WebSockets, load balancing (L4 vs L7), CDNs, and fault tolerance patterns like circuit breakers.35m
- API Gateway & Load BalancerThe two components every client request hits first — what the gateway does (auth, rate limiting, routing), how a load balancer spreads traffic, and the one idea interviewers probe: plain hashing vs consistent hashing and its replica fix.35m
- CAP Theorem & CachingWhy distributed systems can't have correctness, uptime, and partition tolerance all at once — and the practical CP vs AP choice that follows. Covers replication modes (async, sync, semi-sync), caching strategies (cache-aside, write-through, write-back), eviction policies, TTL, and Redis vs Memcached.35m
- Message Queues & Database LockingHow a queue decouples services and absorbs traffic spikes — RabbitMQ, Kafka, and Amazon SQS compared, with Kafka's partition-ordering caveat. Plus the full lock taxonomy (shared, exclusive, update, schema), row vs table granularity, optimistic vs pessimistic concurrency, and MVCC.35m
- Databases — SQL vs NoSQL, Partitioning & IndexingHow the storage choice is really a choice about scale and consistency — SQL vs NoSQL across six axes, vertical vs horizontal scaling, ACID vs BASE, and what eventual consistency looks like in practice. Then the two levers that keep a big store fast: partitioning (splitting the data) and indexing (finding it).35m
- API Design — REST, gRPC & GraphQLHow backend services talk to each other: the design rules that keep those conversations safe and fast — HTTP methods, status codes, versioning, idempotency, and pagination — then the three styles you actually choose between, and when each one wins.35m
- Tiers of Software ArchitectureEvery application is a set of components — a UI, some logic, a database, maybe a cache or a queue. A tier is a decision about where each of those components physically lives. This chapter walks from the simplest arrangement (everything on one machine) to the sprawling distributed systems behind Instagram and Uber, and shows why each step up the ladder exists.35m
- Web Architecture, From Client to Server and BackHow a browser talks to a backend, why we put an API in between, and every technique for moving data across that gap, from plain requests to persistent real-time streams.35m
- Scalability, from First PrinciplesWhy an app that flies with a thousand users chokes at a million, and the moves that keep response time flat as the crowd grows.35m
- High AvailabilityHardware dies, code crashes, and people fat-finger configs. High availability is the set of design choices that keep the service up anyway — and this chapter builds them from the failure up.35m
- Load BalancingSend all your traffic to one machine and it buckles. Load balancing is the layer that fans requests across many servers — and it starts, surprisingly, at the level of the domain name you type in.35m
- Monoliths & MicroservicesMonolith versus microservices isn't a binary — it's a spectrum with a big ball of mud at one end and a fleet of independently deployed services at the other, plus several structured stops in between that let you get the benefits of separation without the operational tax.35m
- Micro FrontendsYou split the backend into services owned by autonomous teams — then handed the whole frontend to one central UI team, recreating the monolith you were trying to escape. Micro frontends carry the split up through the interface.35m
- DatabasesThere's no "best" database — only the right one for a use case. This chapter builds the vocabulary to choose: the shape of your data, the consistency you can afford, and the specialized stores that each win at exactly one job.35m
- CachingEvery trip to a disk-based database costs time and money. A cache keeps the hot data in memory, intercepting requests so most of them never reach the database at all.35m
- Message QueuesA message queue is a buffer between sender and receiver — so a signup can finish before the email is sent, a feed can push instead of poll, and a million concurrent likes can line up instead of colliding.35m
- Stream ProcessingIoT sensors, social apps, and machines emit data endlessly. Stream processing is the pipeline that collects that flood, standardizes it, analyzes it, and shows it — deciding along the way whether to answer fast or answer accurately.35m
- Architecture Grab-Bag & Picking TechTwo short chapters merged: a grab-bag of architecture patterns the course saved for last (webhooks, shared-nothing, peer-to-peer, and the decentralized web), then the pragmatic checklist for picking a technology stack that won't make you cry into a pillow.35m
- Case Studies & Mobile AppsThe finale: two worked case studies that apply every concept from the course to real services, then the mobile-app playbook — native vs. hybrid, PWAs, and when you even need an app at all.35m
- Concurrency in Online ServicesOne book, one database, two buyers clicking "purchase" at the same instant. Everything in this chapter — isolation levels, locks, snapshot isolation — exists to make sure exactly one of them succeeds and the data never lies.35m
- Handling Database GrowthThe bookstore took off, the data swelled, queries slowed. This chapter splits one database into many — partitioning it, replicating it, and then confronting the hard problem that follows: when several nodes accept writes at once, whose version wins?35m
- Distributed TransactionsOnce your data lives on many shards, a single purchase can touch several of them at once — and there's no shared lock to keep it atomic. This chapter covers the two ways to pull that off, why real companies avoid it when they can, and how they scale it when they can't.35m
- Live Sports Streaming at ScaleThe 2018 FIFA final drew a combined 1.12 billion live viewers. This chapter follows one frame of that stream from the camera to the phone — encoding, edge caching, real-time validation, Kafka's speed tricks, storage math, and how you keep the whole thing standing on game day when traffic climbs by millions of hits per minute.35m
- Video-on-Demand ArchitectureThe video-on-demand module — replays, highlights, fan uploads, a Netflix/YouTube inside your sports service. This chapter follows a video from the moment it lands in a bucket through a stateless processing workflow, out to edge caches worldwide, and into a data model that has to store a web of relationships between users, channels, and videos.35m
- Feeds, Notifications & CMSThree services that all answer one question — "what should this user see, and when?" A recommendation feed the user pulls , notifications the backend pushes , and a content management system whose article-author-tag-category web finally makes graph databases the obvious choice. All three are wired together by the same change-data-capture-into-Kafka backbone.35m
- Distributed Content SearchDatabases store data; they don't search it well. This chapter builds a content-search service on Elasticsearch — why a search engine beats a database, how an inverted index turns text into instant lookups, how a query fans out across a cluster with no single point of failure, and the immutable-segment trick that makes near-real-time search possible.35m
- Distributed PaymentsThe subscription-payment service — where getting it wrong means double-charging a customer or losing a sale. This chapter traces a card payment through six intermediaries you don't control, then builds a backend on Saga (no locks across banks), event sourcing (an immutable timeline you can replay), and idempotency (click purchase ten times, get charged once).35m
- Weaving Services Together & InterviewsEight chapters built eight services. This one wires them together — how microservices communicate, find each other in a shifting network, and offload the plumbing to a service mesh — then closes the course with the part that actually gets you hired: how to handle a system-design interview, including one for a system you've never heard of.35m