This note covers all 12 topics in kid-language plus the grown-up words you need to remember. Full detail lives in each linked note.

1. What is System Design? 🏗️

what-is-system-design

Kid version: You're opening a pizza shop. Before cooking, you plan: Where's the kitchen? How many ovens? Who takes orders? What if 1,000 people show up at once? Planning all of that before problems happen = system design.

Grown-up words: - Functional = what it does ("make pizza, take orders"). - Non-functional = how well ("fast, never closed, never loses an order"). ← this is where interviews are won. - There's never a perfect plan, only trade-offs: fast or cheap or simple — pick.

Remember: Design = plan for scale, speed, and staying open, and always name the trade-off.

2. Vertical vs Horizontal Scaling 💪

horizontal-vs-vertical-scaling

Kid version: Too many pizza orders! Two ways to cook faster: - Vertical (scale up): buy ONE giant super-oven. Fast, but there's a biggest-oven-in-the-world limit, and if it breaks, no pizza at all. 😱 - Horizontal (scale out): buy LOTS of normal ovens. Add as many as you want, and if one breaks the others keep going. 👍

Grown-up words: Scale up = bigger machine. Scale out = more machines. Real systems scale out, put a load balancer (a host who sends each customer to a free oven), and keep workers stateless (any oven can handle any order).

Remember: More small ovens beats one giant oven.

3. Capacity Estimation 🔢

capacity-estimation

Kid version: Before opening, you guess: "About how many pizzas per hour? How much cheese do I need? How big a fridge?" Guessing with rough math so you buy the right amount.

Grown-up words: Estimate QPS (orders per second), storage (how much data you keep), bandwidth (how much you send). Round hard, split reads vs writes. Handy fact: a day ≈ 100,000 seconds, so per-day ÷ 100,000 = per-second.

Remember: Do rough math first so you scale the right thing.

4. What is HTTP? 🗣️

http

Kid version: HTTP is the waiter. You (browser) say "One pizza please" (request). The waiter brings pizza or says "sorry, sold out" (response). The waiter forgets you the moment they walk away — every order starts fresh.

Grown-up words: HTTP = stateless request/response. - Methods: GET (read), POST (create), PUT/PATCH (change), DELETE (remove). - Status codes: 2xx yay, 3xx go-look-elsewhere, 4xx your mistake (404 not found), 5xx shop's mistake. - HTTPS = HTTP whispering in secret code (TLS) so no one spies.

Remember: HTTP = polite waiter who forgets you after every order.

5. The TCP/IP Stack 📮

tcp-ip-stack

Kid version: How does your order actually reach the shop across town? Like mailing a letter, it passes through layers: you write it → put it in an envelope → the post office routes it → the mail truck drives it. Each layer has ONE job.

Grown-up words: Layers = Application (HTTP) → Transport (TCP/UDP) → Internet (IP) → Link (wire/wifi). - TCP = careful mail: confirms delivery, resends lost letters, keeps order. (web, APIs) - UDP = fast mail: fire and forget, some may get lost. (video calls, games) - TCP starts with a 3-way handshake: "Hi? / Hi back? / Great!" before talking.

Remember: Layers = envelopes inside envelopes. TCP = careful, UDP = fast.

6. What Happens When You Enter Google.com? 🌍

what-happens-when-you-visit-google

Kid version: This is the WHOLE journey of ordering one pizza, start to finish: 1. DNS — you know the shop's name but not its address; you ask a phone book for the address. 📖 2. TCP handshake — you call and say hi, they say hi back. 3. TLS — you switch to secret code so nobody hears your order. 4. HTTP — you finally say "one pizza!" 5. Kitchen — the host (load balancer) picks a free cook, who maybe grabs a ready pizza from the warmer (cache) or checks the recipe book (database). 6. Delivery + render — pizza arrives; you unbox and eat (browser draws the page).

Grown-up words: DNS → TCP → TLS → HTTP → server (LB → app → cache/DB) → response → render. This one question secretly tests the entire stack.

Remember: Name → address → hello → secret code → order → kitchen → eat.

7. Relational Databases (SQL) 🗄️

relational-databases

Kid version: A super-strict filing cabinet. Every customer form must be filled in exactly right — no missing boxes. Everything is neat, and forms connect to each other ("this order belongs to that customer").

Grown-up words: Data in tables with a fixed schema, linked by keys, queried with SQL. Gives ACID = money-safe promises (all-or-nothing, always valid, no mix-ups, never lost). Great for correctness (payments, orders). Downside: hard to spread writes across many machines.

Remember: SQL = strict, tidy, safe filing cabinet. Use it when mistakes must never happen.

8. Database Indexes 🔎

database-indexes

Kid version: Your recipe book has 500 pages. To find "pepperoni," do you read every page? No — you flip to the index at the back and jump straight there.

Grown-up words: An index (usually a B-tree) lets the database jump to rows instead of scanning everything — turns slow O(n) into fast O(log n). Trade-off: faster reads, but slower writes and more storage (every new page means updating the index). Don't index everything.

Remember: Index = shortcut to find stuff fast; costs a little extra work when adding stuff.

9. NoSQL Databases 🧸

nosql-databases

Kid version: Instead of the strict filing cabinet, a giant toy box. Throw anything in, any shape, no strict form. Super easy to add a hundred more toy boxes when you have tons of stuff.

Grown-up words: Non-relational stores; flexible schema; scale out easily. Types: key-value (Redis), document (MongoDB), wide-column (Cassandra), graph (Neo4j). Often eventually consistent (copies catch up in a moment).

SQL vs NoSQL: strict + safe + connected → SQL. Huge + flexible + simple lookups → NoSQL. (Real apps use both!)

Remember: SQL = tidy cabinet. NoSQL = giant flexible toy box that's easy to copy.

10. What is a Cache? 🍪

caching

Kid version: Instead of walking to the far kitchen every time you're hungry, keep some cookies in your pocket. Grab-and-go for the snacks you eat most. Way faster.

Grown-up words: A cache stores hot data in a faster/closer layer (like Redis, or a CDN at the "edge" near users) so most requests skip the slow database. Works because of locality (a few things get used a lot). Strategy: cache-aside (check pocket first). Hard parts: invalidation (what if a cookie goes stale?) and stampede (everyone raids the kitchen at once). Measure with hit ratio.

Remember: Cache = snacks in your pocket. Fast, but you must keep them fresh. (This is the same idea as the CPU Cache Memory note — just a different layer.)

11. What is Thrashing? 🌀

thrashing

Kid version: One tiny table, but 20 kids doing homework. Only 2 can sit at a time, so everyone keeps swapping seats — stand up, sit down, stand up — and nobody actually finishes homework. Busy, but useless.

Grown-up words: When the working set (stuff you're using now) doesn't fit in RAM, the computer spends all its time swapping pages to slow disk instead of working. Throughput collapses. Fix: fewer things at once, or more RAM. Same idea as a cache with a hit ratio too low to help.

Remember: Thrashing = so much swapping that no real work gets done.

12. What are Threads? 🧑‍🍳🧑‍🍳

threads

Kid version: One cook is slow. Hire many cooks in the same kitchen — one chops, one bakes, one boxes — all at once. But if two grab the same knife at the same time... uh oh. 🔪

Grown-up words: A thread = one worker inside a process. Many threads share memory and run at once = concurrency (juggling many things) / parallelism (truly at the same time on many cores). Danger: race conditions (two threads clash) and deadlock (both wait forever). Fix with locks.

Remember: Threads = many cooks in one kitchen. Powerful, but they must not grab the same knife.

🎯 Whole thing in 6 sentences

1. System design = planning your pizza shop for huge crowds.
2. Serve more people with more ovens (horizontal scaling) behind a host (load balancer), and guess demand first (capacity estimation).
3. Orders travel by polite waiter (HTTP) through layers of mail (TCP/IP), and one order's full journey is the "what happens when you visit Google" story (DNS→TCP→TLS→HTTP→render).
4. Store facts in a strict cabinet (SQL) or a flexible toy box (NoSQL), and find them fast with an index.
5. Keep hot stuff in your pocket (cache) so you skip the slow kitchen.
6. Watch out for too-much-swapping (thrashing) and use many cooks carefully (threads).

The reusable framework (apply to every problem)

Copy this into a new note per case study:

1. Requirements
   - Functional: (what it must do)
   - Non-functional: scale, latency, availability, consistency
2. Capacity estimation  → <a class="wl" href="#capacity-estimation">capacity-estimation</a>
   - DAU, read/write QPS, storage, bandwidth
3. API design           → <a class="wl" href="#api-design">api-design</a>
4. Data model           → <a class="wl" href="#relational-databases">relational-databases</a> / <a class="wl" href="#nosql-databases">nosql-databases</a>
5. High-level design (draw boxes: client → LB → services → DB/cache/queue)
6. Deep dives (pick 1–2 hard parts)
7. Bottlenecks & scaling → <a class="wl" href="#caching">caching</a> · <a class="wl" href="#sharding">sharding</a> · <a class="wl" href="#data-replication">data-replication</a> · <a class="wl" href="#load-balancing">load-balancing</a>
8. Trade-offs made       → <a class="wl" href="#tradeoff-consistency-vs-availability">tradeoff-consistency-vs-availability</a> etc.

The 17 problems + what each teaches

Video-based (takeUforward)

Text-based (InterviewReady)

Additional resources (from the roadmap)

• InterviewReady course
• System Design Resources (GitHub)
• Designing Data-Intensive Applications — the canonical book

Related

system-design-eli10 · what-is-system-design · capacity-estimation · api-design

Three self-test Q&A pages, now in the vault at raw/. User reports having worked through these (2026-08-17). Open them in a browser — each has a Hide answers self-test mode and a print option.

What each covers

Core Roadmap (12 sections) — Basics · Load Balancing · DataStores · Consistency vs Availability · Message Queues · DevOps Concepts · Caching · Microservices · API Gateways · Authentication · Trade-offs · Practice Problems.

This maps almost exactly onto the vault's 52 concept notes — same sections, same order. The roadmap sheet is the Q&A version of the concept layer already scaffolded here.

HLD (6 groups) — architecture & design choices · scalability, availability, reliability · data management · caching & CDN · distributed systems & communication · networking fundamentals. Ends with an HLD vs LLD summary.

LLD (7 groups) — foundations · OOP · design principles (SOLID, DRY, KISS, YAGNI, coupling, DI) · design patterns concepts · specific patterns (Singleton, Observer, Factory, Abstract Factory, Strategy, Proxy vs Decorator, Chain of Responsibility, Command, Null Object) · UML · data/DB/system-level LLD.

⚠️ The gap this exposes

The vault has zero LLD notes. All 54 System Design notes are HLD/distributed-systems

That matters because LLD is usually its own interview round, especially for SDE roles at Indian product companies — the same companies behind the IRCTC/UPI/Doordash problems in practice-problems. A strong HLD round doesn't substitute for it.

The LLD sheet is a revision asset, not a substitute for practice: LLD rounds ask you to write class designs (parking lot, elevator, splitwise, BookMyShow), which is a different skill from answering "what is the Strategy pattern?"

How this changes the plan

0–1 (15 h) is largely already done**. What remains:

Verification beats assumption: open the roadmap sheet in Hide answers mode and run a section. If you reconstruct the answers cold, the concept layer is genuinely done and the sprint drops to practice problems + LLD. If not, the sheet tells you exactly which sections to revisit — which is faster than reworking all 13 open notes.

Related

Same 217 problems as codemia-catalog, regrouped so everything sharing an architecture sits together. E/M/H/A = difficulty · ⭐ = one of your Core 12.

If you only do 14 problems

One per architecture. Finish these and you have touched every skeleton in the catalog.

1. Designing a Simple URL Shortening Service: A TinyURL Approach — Key generation & counting
2. Design an API Rate Limiter — Coordination, limits & locks
3. Design Twitter — Feeds & fan-out
4. Design Facebook Messenger — Real-time messaging & presence
5. Design Uber Backend — Geospatial & dispatch
6. Design Ticketmaster — Booking & inventory — never double-book
7. Design a Task Scheduler — Async jobs & workflows
8. Design an Online Payment Service — Money, ledgers & idempotency
9. Design a Web Crawler — Search, crawl & rank
10. Design Youtube or Netflix — Media pipeline & CDN
11. Design an Ad Click Aggregation System — Streaming analytics & aggregation
12. Design Dropbox — Sync, files & collaboration
13. Design a Key Value Store — Storage engines & infra primitives
14. Design ChatGPT — AI / LLM serving

127 System Design problems reduce to 15 skeletons. 14 of those matter for interviews. That is the whole point of this page.

System Design patterns

Key generation & counting  _{8 problems}

Skeleton: hash/encode a key → store → read-heavy lookup + cache

Every one is: make a short unique key, write it once, read it a million times. The whole interview is key generation, collisions and the read:write skew.

🎯 Learn this one: Designing a Simple URL Shortening Service: A TinyURL Approach — then the rest are variations.

• [ ] E Designing a Simple URL Shortening Service: A TinyURL Approach ⭐
• [ ] E Design Pastebin
• [ ] E Design a Tagging Service
• [ ] E Design a Multi-Device Screenshot Capture System
• [ ] E Design a Video View Count System
• [ ] M Design a Distributed Counter
• [ ] M Design a Distributed Unique Id Generator ⭐
• [ ] M Design a QR Code System for a Grocery Shop

Coordination, limits & locks  _{7 problems}

Skeleton: shared counter or lease in Redis → token bucket → distributed lock with TTL

You will bolt rate limiting onto almost every other design in this list. Learn it once, reuse it in ten interviews.

🎯 Learn this one: Design an API Rate Limiter — then the rest are variations.

• [ ] M Design an API Rate Limiter ⭐
• [ ] M Design a Distributed Locking System
• [ ] M Design a CAPTCHA System
• [ ] H Design a Load Balancer
• [ ] H Design a Secure Identity Management System
• [ ] H Design a Resource Allocation Service
• [ ] H Design a Service to Allocate Pool of Resources Optimally

Feeds & fan-out  _{10 problems}

Skeleton: post → fan-out on write <i>or</i> read → timeline cache → rank

One decision drives all of them: build the timeline when content is posted, or when the app is opened. Celebrity/hot-key problem is the follow-up every time.

🎯 Learn this one: Design Twitter — then the rest are variations.

• [ ] E Design a Nested Comments System
• [ ] E Design Craigslist
• [ ] M Design Twitter ⭐
• [ ] M Design Instagram
• [ ] M Design an Ebook Distribution Platform
• [ ] M Design a Podcast Hosting Platform
• [ ] M Design a Platform Like Reddit
• [ ] M Design a Digital Distribution Platform for Applications
• [ ] H Design Facebook's Newsfeed
• [ ] H Design TikTok

Real-time messaging & presence  _{10 problems}

Skeleton: persistent connection (WebSocket) → delivery guarantee → offline queue → heartbeat presence

All share: who is connected, how does a message survive the recipient being offline, and how do you order messages across devices.

🎯 Learn this one: Design Facebook Messenger — then the rest are variations.

• [ ] E Design an Online Presence Indicator Service
• [ ] M Design Facebook Messenger ⭐
• [ ] M Design an Online Chess Service
• [ ] M Design a Video Conferencing system
• [ ] M Design a Real Time Sports Scoring System
• [ ] M Design a Live Comment System
• [ ] M Design a Collaboration Tool for Team Communication
• [ ] M Design a Webhook Notification Service
• [ ] H Design a Scalable Email Service
• [ ] H Design a Push Notification Service

Geospatial & dispatch  _{11 problems}

Skeleton: geo index (geohash / quadtree) → proximity query → match → live location stream

The index is the whole problem — a B-tree can't answer "who is within 2 km". Then matching, and locking so one driver isn't double-assigned.

🎯 Learn this one: Design Uber Backend — then the rest are variations.

• [ ] E Design a Fitness Tracking App
• [ ] E Design a Weather Reporting System
• [ ] E Design a Network Connection Path Analyzer
• [ ] M Design a Public Transportation System
• [ ] M Design an Air Traffic Control System
• [ ] M Design a Fresh Grocery Delivery System
• [ ] M Design a Server Architecture for Serving Geospatial Images
• [ ] H Design Uber Backend ⭐
• [ ] H Design Yelp or Nearby Friends
• [ ] H Design Google Map
• [ ] H Design a Food Delivery Service

Booking & inventory — never double-book  _{12 problems}

Skeleton: hold → reserve → confirm, guarded by a lock or optimistic concurrency

The only pattern where strong consistency is the headline requirement. Two users, one seat. Everything else is CRUD around that.

🎯 Learn this one: Design Ticketmaster — then the rest are variations.

• [ ] E Design an Efficient Parking Lot System
• [ ] E Design an Employee Swap System
• [ ] E Design a Conference Room Booking System
• [ ] M Design an Inventory Management System
• [ ] M Design a Voting System
• [ ] M Design an Online Coupon Service
• [ ] M Design a Flash Sale System
• [ ] M Design a Meeting Calendar System
• [ ] M Design a Collaborative Meeting Scheduler
• [ ] H Design Ticketmaster ⭐
• [ ] H Design a Hotel Booking Service
• [ ] H Design an Auction system

Async jobs & workflows  _{9 problems}

Skeleton: queue → workers → state machine → retries + idempotent execution

Leases, fencing tokens, at-least-once delivery, and making re-execution safe. Order tracking and CI pipelines are the same engine.

🎯 Learn this one: Design a Task Scheduler — then the rest are variations.

• [ ] M Design a Task Scheduler
• [ ] M Design a Task Management Application
• [ ] M Design a Code Deployment System
• [ ] M Design a Database Batch Auditing Service
• [ ] M Design a Competitive Programming Platform
• [ ] M Design an Order Tracking System
• [ ] M Design an Airport Baggage Handling System
• [ ] H Design an Event Lifecycle Management System
• [ ] H Design GitHub Actions

Money, ledgers & idempotency  _{9 problems}

Skeleton: double-entry ledger + idempotency keys + saga for multi-step

Exactly-once is a goal you approximate. Idempotency keys, ledgers that never UPDATE, and reconciliation are the recurring answers.

🎯 Learn this one: Design an Online Payment Service — then the rest are variations.

• [ ] M Design an E-commerce Service
• [ ] M Design an Online Payment Service ⭐
• [ ] M Design a Blockchain Based System
• [ ] M Design Shopify
• [ ] M Design a Digital Wallet
• [ ] M Design an ATM Machine System
• [ ] H Design an Automated Trading Platform
• [ ] H Design a Real Time Stock Trading Platform
• [ ] H Design a Scheduled Digital Transaction System

Search, crawl & rank  _{9 problems}

Skeleton: crawl/ingest → inverted index → rank → query serving

Inverted index + sharding by term + near-real-time indexing. Typeahead is the same machinery with a trie and a 100 ms budget.

🎯 Learn this one: Design a Web Crawler — then the rest are variations.

• [ ] M Design Typeahead Suggestion
• [ ] M Design Twitter Search
• [ ] M Design a Frequently Viewed Products Feature
• [ ] M Design an E-commerce Recommendation System
• [ ] M Design a Movie Reviews Aggregator System
• [ ] H Design a Web Crawler
• [ ] H Design Google Search
• [ ] H Design a Graph Search Function for a Social Network
• [ ] H Design a Web Crawler That Will Crawl Wikipedia

Media pipeline & CDN  _{7 problems}

Skeleton: upload → transcode workers → object store → CDN edge → adaptive bitrate

These are bandwidth and storage problems wearing a compute costume. Same pipeline whether it's video, audio or ebooks.

🎯 Learn this one: Design Youtube or Netflix — then the rest are variations.

• [ ] M Design Youtube or Netflix ⭐
• [ ] M Design Spotify
• [ ] M Design a Live Video Streaming Platform
• [ ] M Design a Language Translation Service
• [ ] H Design a Global Content Distribution Network
• [ ] H Design Sora
• [ ] A Design a Virtual Reality Streaming Service

Streaming analytics & aggregation  _{7 problems}

Skeleton: high-volume ingest → stream processor → time-series store → rollups

Counting at scale: dedup, windowing, approximate structures, hot partitions. Metrics, logs and traces are one pattern in three costumes.

🎯 Learn this one: Design an Ad Click Aggregation System — then the rest are variations.

• [ ] M Design a Web Analytics Tool
• [ ] M Design a Top-K Request Analysis System
• [ ] H Design a Log Collection and Analysis System
• [ ] H Design a Distributed Tracing System
• [ ] H Design a Metrics Monitoring and Alerting System
• [ ] H Design an Ad Click Aggregation System
• [ ] A Design a Network Security Monitoring Tool

Sync, files & collaboration  _{7 problems}

Skeleton: chunk + dedup + version vectors; OT/CRDT when text is edited concurrently

Conflict resolution is the whole game. Dropbox = file-level; Google Docs = character-level (OT/CRDT). Learn Dropbox first, then the CRDT jump.

🎯 Learn this one: Design Dropbox — then the rest are variations.

• [ ] M Design a Collaborative Online Spreadsheet System
• [ ] H Design Dropbox
• [ ] H Design Google Doc
• [ ] H Design a Peer-to-Peer Network
• [ ] H Design a Distributed File System
• [ ] A Design a Cloud Based Data Backup Solution
• [ ] A Design a Cloud Storage Gateway

Storage engines & infra primitives  _{8 problems}

Skeleton: partition → replicate → quorum / consensus → compaction

This is the Dynamo paper wearing different hats. Consistent hashing, quorum reads/writes, anti-entropy, LSM trees.

🎯 Learn this one: Design a Key Value Store — then the rest are variations.

• [ ] M Design a Web Cache ⭐
• [ ] H Design a Key Value Store ⭐
• [ ] H Design a Distributed Messaging System
• [ ] H Design a Smart Home System
• [ ] H Design a Distributed Linked List
• [ ] H Design a Wide Column Database
• [ ] A Design a Distributed OLTP Database
• [ ] A Design a Domain Name System

AI / LLM serving  _{5 problems}

Skeleton: model server → request batching → KV cache → GPU scheduling → streaming tokens

Increasingly asked, and directly relevant to your AI track. GPU scheduling and KV-cache management are the parts people miss.

🎯 Learn this one: Design ChatGPT — then the rest are variations.

• [ ] E Design a Sentiment Analysis System
• [ ] M Design a Spam Detection System
• [ ] H Design a Chatbot Framework
• [ ] H Design ChatGPT ⭐
• [ ] H Design an LLM Inference Service

Cloud & platform infrastructure  _{10 problems}

Skeleton: orchestration, virtualization, multi-region failover

Rarely asked outside infra-specific roles. Skip until the other 14 are solid.

• [ ] E Design a Vending Machine System
• [ ] A Design a Container Orchestration System
• [ ] A Design a High-Performance Computing Cluster
• [ ] A Design a Virtualization System
• [ ] A Design a Disaster Recovery System
• [ ] A Design a Hybrid Cloud Workload Orchestrator
• [ ] A Design a Multi-Cloud API Gateway
• [ ] A Design a Serverless Architecture Framework
• [ ] A Design a Large-Scale Graph Processing System
• [ ] A Design a Big Data Processing Pipeline

Object-Oriented Design patterns (LLD)

State machines  _{8 problems}

Skeleton: states + transitions + guards; one object owns the current state

Elevator, traffic light, vending machine, ATM — identical skeleton, different labels.

🎯 Learn this one: Design an Elevator System — then the rest are variations.

• [ ] E Design a Vending Machine
• [ ] E Design a Traffic Light System
• [ ] E Design a Coffee Machine
• [ ] M Design an Elevator System
• [ ] M Design an ATM
• [ ] H Design a Workflow Engine
• [ ] A Design a Game State Management System
• [ ] A Design an Operating System Task Scheduler

Command, undo & pipelines  _{6 problems}

Skeleton: encapsulate an action as an object → stack for undo/redo → chain for pipelines

Command pattern. Once you've built undo/redo, middleware chains and plugin systems are the same idea.

🎯 Learn this one: Design a Text Editor with Undo/Redo — then the rest are variations.

• [ ] M Design an Event Emitter
• [ ] H Design a Text Editor with Undo/Redo
• [ ] H Design a Business Rule Engine
• [ ] H Design a Plugin System
• [ ] H Design a Middleware Chain
• [ ] A Design a Code Editor

Reservation & pricing  _{11 problems}

Skeleton: resource + availability calendar + booking + pricing strategy

The most-asked LLD problem family. Strategy pattern for pricing, factory for resource types.

🎯 Learn this one: Design a Parking Lot — then the rest are variations.

• [ ] E Design a Parking Lot
• [ ] M Design a Hotel Booking System
• [ ] M Design a Library Management System
• [ ] M Design a Movie Ticket Booking System
• [ ] M Design a Restaurant Order System
• [ ] M Design a Car Rental System
• [ ] M Design an Airline Booking System
• [ ] M Design an Online Auction System
• [ ] M Design a Coupon and Discount System
• [ ] H Design a Calendar System
• [ ] H Design a Parking Garage with Dynamic Pricing

Composite trees & boards  _{12 problems}

Skeleton: recursive part-whole hierarchy; uniform treatment of leaf and node

File systems, spreadsheets and game boards are all composites. Chess adds strategy-per-piece.

🎯 Learn this one: Design a File System — then the rest are variations.

• [ ] E Design a Tic-Tac-Toe Game
• [ ] E Design a Deck of Cards
• [ ] M Design a Chess Game
• [ ] M Design a Bowling Alley System
• [ ] M Design a Snake Game
• [ ] M Design a Blackjack Game
• [ ] H Design a File System
• [ ] H Design a Spreadsheet
• [ ] H Design a Multi-player Card Game Framework
• [ ] A Design an Entity-Component System
• [ ] A Design a Board Game Framework
• [ ] A Design a Game Physics Engine

Observer & notification  _{9 problems}

Skeleton: subject holds subscribers → state change → notify all

Pub/sub in object form. Chat, logging and event emitters are the same wiring.

🎯 Learn this one: Design a Notification System — then the rest are variations.

• [ ] E Design a Logger System
• [ ] M Design a Social Media Platform
• [ ] M Design an IoT Smart Home System
• [ ] M Design a Music Player
• [ ] M Design a Chat Application
• [ ] H Design a Notification System
• [ ] H Design a Video Streaming Platform
• [ ] H Design an Email Client
• [ ] H Design a Music Streaming App

Accounts & transactions  _{7 problems}

Skeleton: account entities + transaction objects + invariants that must never break

Encapsulation is the lesson: balance must be unreachable except through methods that preserve invariants.

🎯 Learn this one: Design a Banking System — then the rest are variations.

• [ ] E Design a Bank Account System
• [ ] M Design a Banking System
• [ ] M Design an Online Shopping System
• [ ] M Design a Voting Booth System
• [ ] H Design a Payment Gateway System
• [ ] H Design a Stock Portfolio Manager
• [ ] H Design an E-commerce Cart and Checkout

Core data structures  _{7 problems}

Skeleton: build the primitive itself with correct complexity

Hashmap + doubly linked list. Closest thing to a DSA question in the LLD round.

🎯 Learn this one: Design an LRU Cache — then the rest are variations.

• [ ] E Design a Stack and Queue
• [ ] E Design a Shape Calculator
• [ ] H Design an Object Pool
• [ ] A Design a Resource Management System
• [ ] A Design a Compiler Lexer and Parser
• [ ] A Design an LRU Cache
• [ ] A Design a Permission and Role System

Domain CRUD systems  _{10 problems}

Skeleton: entities + relationships + roles + lifecycle

Bread-and-butter modelling. Get the entity relationships and roles right; resist over-engineering.

• [ ] M Design a Warehouse Management System
• [ ] M Design a Learning Management System
• [ ] M Design a Ride-Sharing Service
• [ ] M Design a Task Management System
• [ ] M Design a Pharmacy Management System
• [ ] M Design a Contact Management System
• [ ] M Design a Warehouse Inventory Tracker
• [ ] M Design a Workout Planner
• [ ] H Design a File Sharing Platform
• [ ] H Design a Food Delivery System

Agentic AI patterns

Single-agent RAG  _{3 problems}

Skeleton: ingest → chunk/index → retrieve → generate with citations

The base case. Everything else adds tools or agents on top of this.

🎯 Learn this one: Design a RAG-Based Q&A Agent — then the rest are variations.

• [ ] E Design a RAG-Based Q&A Agent
• [ ] E Design a Personal Finance Agent
• [ ] M Design a Document Processing Agent

Tool-using task agents  _{5 problems}

Skeleton: agent loop + tool schemas + planning + result validation

The ReAct loop from your LangGraph notes, applied to a domain.

🎯 Learn this one: Design a Data Analysis Agent — then the rest are variations.

• [ ] E Design an AI Travel Planning Agent
• [ ] M Design a Customer Support Agent
• [ ] M Design a Data Analysis Agent
• [ ] M Design a Workflow Automation Agent
• [ ] M Design a Sales Development Agent

Code agents  _{2 problems}

Skeleton: repo context → plan → edit → run tests → iterate

Verification is the design problem: the tests are the feedback loop.

🎯 Learn this one: Design a Code Generation Agent — then the rest are variations.

• [ ] M Design a Code Generation Agent
• [ ] H Design an Autonomous Testing Agent

Multi-agent orchestration  _{2 problems}

Skeleton: coordinator + workers + shared state + handoff protocol

Supervisor pattern — same shape as your LangGraph multi-agent note.

🎯 Learn this one: Design a Multi-Agent Orchestration System — then the rest are variations.

• [ ] H Design a Deep Research Agent
• [ ] H Design a Multi-Agent Orchestration System

Safety-critical agents  _{4 problems}

Skeleton: input filter → agent → output validation → human-in-the-loop escalation

Guardrails as architecture, not prompt text. Maps to CCAR-P Domain 5.

🎯 Learn this one: Design an AI Content Moderation Agent — then the rest are variations.

• [ ] H Design a Security Monitoring Agent
• [ ] H Design an AI Content Moderation Agent
• [ ] A Design a Medical Triage Agent
• [ ] A Design an Autonomous Trading Agent

Agent runtimes & platforms  _{2 problems}

Skeleton: sandboxing + tool registry + session state + observability + billing

Platform-level thinking. Closest thing to what Anthropic's Managed Agents does.

🎯 Learn this one: Design an AI Agent Runtime Platform — then the rest are variations.

• [ ] H Design an AI Agent Runtime Platform
• [ ] H Design an Agent Execution Standard

Why this ordering

The System Design patterns are sequenced by dependency, not difficulty. Key generation (P1) and coordination (P9) show up inside almost every later design — rate limiting bolts onto everything, and locks reappear in dispatch, booking and money. Learning those two first means every later pattern has fewer new parts.

Related

Complete listing from codemia.io, captured 2026-08-21. Checkboxes are live — tick as you complete them.

All 12 Core problems exist here, so this site can be your single practice surface.

⭐ Two things here that fill real gaps

1. The OOD track is the LLD gap, solved. revision-sheets flagged that the vault has zero LLD notes while LLD is usually its own interview round. These 70 problems are exactly that round — parking lot, elevator, chess, text editor with undo/redo, LRU cache. Start with Elevator, Parking Lot, and Text Editor with Undo/Redo: they cover state machines, strategy/factory, and the command pattern, which is most of what LLD interviews test.

2. The Agentic AI track maps onto your AI Engineering work. 18 problems covering RAG agents, multi-agent orchestration, agent runtimes, content moderation and evals — the same ground as langgraph-05-multi-agent, vectorless-rag-pageindex and llm-evaluation-langsmith, and directly useful for claude-cert-ccarp Domain 1 (Solution Design) and Domain 3 (Integration). Design a RAG-Based Q&A Agent and Design a Multi-Agent Orchestration System are the two closest to your portfolio project.

System Design

127 problems

Easy (15)

• [ ] Designing a Simple URL Shortening Service: A TinyURL Approach ⭐ Core 1 TinyURL
• [ ] Design an Efficient Parking Lot System
• [ ] Design a Fitness Tracking App
• [ ] Design a Weather Reporting System
• [ ] Design Pastebin
• [ ] Design a Nested Comments System
• [ ] Design an Online Presence Indicator Service
• [ ] Design a Vending Machine System
• [ ] Design a Tagging Service
• [ ] Design Craigslist
• [ ] Design a Multi-Device Screenshot Capture System
• [ ] Design a Network Connection Path Analyzer
• [ ] Design an Employee Swap System
• [ ] Design a Conference Room Booking System
• [ ] Design a Video View Count System

Medium (55)

• [ ] Design Twitter ⭐ Core 6 Twitter ⭐
• [ ] Design Facebook Messenger ⭐ Core 7 WhatsApp/Messenger
• [ ] Design an API Rate Limiter ⭐ Core 3 Rate limiter
• [ ] Design Youtube or Netflix ⭐ Core 8 YouTube/Netflix
• [ ] Design Typeahead Suggestion ◆ Stretch Typeahead
• [ ] Design Twitter Search
• [ ] Design Instagram
• [ ] Design an Online Chess Service
• [ ] Design a Web Cache ⭐ Core 4 Distributed cache
• [ ] Design a Task Scheduler ◆ Stretch Job scheduler
• [ ] Design an E-commerce Service
• [ ] Design an Inventory Management System
• [ ] Design an Online Payment Service ⭐ Core 11 Payments
• [ ] Design Spotify
• [ ] Design a Live Video Streaming Platform
• [ ] Design a Video Conferencing system
• [ ] Design an Ebook Distribution Platform
• [ ] Design a Blockchain Based System
• [ ] Design a Web Analytics Tool
• [ ] Design a Public Transportation System
• [ ] Design a Language Translation Service
• [ ] Design a Task Management Application
• [ ] Design a Voting System
• [ ] Design a Real Time Sports Scoring System
• [ ] Design a Podcast Hosting Platform
• [ ] Design Shopify
• [ ] Design a Digital Wallet
• [ ] Design a Code Deployment System
• [ ] Design a Live Comment System
• [ ] Design a Distributed Counter
• [ ] Design a Distributed Locking System
• [ ] Design a Platform Like Reddit
• [ ] Design a CAPTCHA System
• [ ] Design a Database Batch Auditing Service
• [ ] Design a Distributed Unique Id Generator ⭐ Core 2 Unique ID
• [ ] Design an Online Coupon Service
• [ ] Design a Flash Sale System
• [ ] Design an ATM Machine System
• [ ] Design a Meeting Calendar System
• [ ] Design a Collaboration Tool for Team Communication
• [ ] Design a Webhook Notification Service
• [ ] Design a Frequently Viewed Products Feature
• [ ] Design an E-commerce Recommendation System
• [ ] Design an Air Traffic Control System
• [ ] Design a Digital Distribution Platform for Applications
• [ ] Design a Competitive Programming Platform
• [ ] Design a Fresh Grocery Delivery System
• [ ] Design a Movie Reviews Aggregator System
• [ ] Design a Collaborative Meeting Scheduler
• [ ] Design a Server Architecture for Serving Geospatial Images
• [ ] Design a QR Code System for a Grocery Shop
• [ ] Design a Top-K Request Analysis System
• [ ] Design an Order Tracking System
• [ ] Design a Collaborative Online Spreadsheet System
• [ ] Design an Airport Baggage Handling System

Hard (42)

• [ ] Design Ticketmaster ⭐ Core 10 Ticketmaster
• [ ] Design Dropbox
• [ ] Design Uber Backend ⭐ Core 9 Uber
• [ ] Design Yelp or Nearby Friends
• [ ] Design Facebook's Newsfeed
• [ ] Design a Web Crawler ◆ Stretch Web crawler
• [ ] Design Google Map
• [ ] Design Google Doc ◆ Stretch Google Docs
• [ ] Design an Automated Trading Platform
• [ ] Design a Key Value Store ⭐ Core 5 KV store
• [ ] Design a Global Content Distribution Network
• [ ] Design a Peer-to-Peer Network
• [ ] Design a Distributed Messaging System
• [ ] Design a Distributed File System
• [ ] Design a Log Collection and Analysis System
• [ ] Design a Load Balancer
• [ ] Design a Scalable Email Service
• [ ] Design a Food Delivery Service
• [ ] Design a Hotel Booking Service
• [ ] Design an Auction system
• [ ] Design a Chatbot Framework
• [ ] Design a Push Notification Service ◆ Stretch Notifications
• [ ] Design a Smart Home System
• [ ] Design a Secure Identity Management System
• [ ] Design a Real Time Stock Trading Platform
• [ ] Design Google Search
• [ ] Design a Scheduled Digital Transaction System
• [ ] Design a Distributed Linked List
• [ ] Design a Distributed Tracing System
• [ ] Design a Wide Column Database
• [ ] Design a Metrics Monitoring and Alerting System ◆ Stretch Metrics/monitoring
• [ ] Design a Graph Search Function for a Social Network
• [ ] Design a Resource Allocation Service
• [ ] Design an Event Lifecycle Management System
• [ ] Design a Web Crawler That Will Crawl Wikipedia
• [ ] Design an Ad Click Aggregation System ◆ Stretch Ad click agg
• [ ] Design a Service to Allocate Pool of Resources Optimally
• [ ] Design Sora
• [ ] Design ChatGPT ⭐ Core 12 ChatGPT ⭐
• [ ] Design an LLM Inference Service
• [ ] Design GitHub Actions
• [ ] Design TikTok

Advanced (15)

• [ ] Design a Container Orchestration System
• [ ] Design a High-Performance Computing Cluster
• [ ] Design a Cloud Based Data Backup Solution
• [ ] Design a Cloud Storage Gateway
• [ ] Design a Virtualization System
• [ ] Design a Disaster Recovery System
• [ ] Design a Hybrid Cloud Workload Orchestrator
• [ ] Design a Multi-Cloud API Gateway
• [ ] Design a Serverless Architecture Framework
• [ ] Design a Large-Scale Graph Processing System
• [ ] Design a Big Data Processing Pipeline
• [ ] Design a Virtual Reality Streaming Service
• [ ] Design a Network Security Monitoring Tool
• [ ] Design a Distributed OLTP Database
• [ ] Design a Domain Name System

Object-Oriented Design (LLD)

70 problems

Easy (10)

• [ ] Design a Parking Lot
• [ ] Design a Vending Machine
• [ ] Design a Tic-Tac-Toe Game
• [ ] Design a Deck of Cards
• [ ] Design a Logger System
• [ ] Design a Stack and Queue
• [ ] Design a Traffic Light System
• [ ] Design a Coffee Machine
• [ ] Design a Bank Account System
• [ ] Design a Shape Calculator

Medium (30)

• [ ] Design a Warehouse Management System
• [ ] Design a Banking System
• [ ] Design an Elevator System
• [ ] Design an Online Shopping System
• [ ] Design a Learning Management System
• [ ] Design an ATM
• [ ] Design a Social Media Platform
• [ ] Design an IoT Smart Home System
• [ ] Design a Chess Game
• [ ] Design a Hotel Booking System
• [ ] Design a Ride-Sharing Service
• [ ] Design a Library Management System
• [ ] Design a Movie Ticket Booking System
• [ ] Design a Restaurant Order System
• [ ] Design a Car Rental System
• [ ] Design an Airline Booking System
• [ ] Design a Task Management System
• [ ] Design an Online Auction System
• [ ] Design a Bowling Alley System
• [ ] Design a Pharmacy Management System
• [ ] Design a Contact Management System
• [ ] Design a Music Player
• [ ] Design a Voting Booth System
• [ ] Design a Coupon and Discount System
• [ ] Design a Warehouse Inventory Tracker
• [ ] Design a Chat Application
• [ ] Design a Snake Game
• [ ] Design a Blackjack Game
• [ ] Design an Event Emitter
• [ ] Design a Workout Planner

Hard (20)

• [ ] Design a File Sharing Platform
• [ ] Design a Food Delivery System
• [ ] Design a File System
• [ ] Design a Calendar System
• [ ] Design a Payment Gateway System
• [ ] Design a Notification System
• [ ] Design a Video Streaming Platform
• [ ] Design a Text Editor with Undo/Redo
• [ ] Design a Spreadsheet
• [ ] Design a Workflow Engine
• [ ] Design a Business Rule Engine
• [ ] Design a Plugin System
• [ ] Design a Stock Portfolio Manager
• [ ] Design a Multi-player Card Game Framework
• [ ] Design an Object Pool
• [ ] Design an Email Client
• [ ] Design a Music Streaming App
• [ ] Design an E-commerce Cart and Checkout
• [ ] Design a Middleware Chain
• [ ] Design a Parking Garage with Dynamic Pricing

Advanced (10)

• [ ] Design a Resource Management System
• [ ] Design a Game State Management System
• [ ] Design an Entity-Component System
• [ ] Design an Operating System Task Scheduler
• [ ] Design a Compiler Lexer and Parser
• [ ] Design an LRU Cache
• [ ] Design a Code Editor
• [ ] Design a Permission and Role System
• [ ] Design a Board Game Framework
• [ ] Design a Game Physics Engine

Agentic AI

18 problems

Easy (3)

• [ ] Design a RAG-Based Q&A Agent
• [ ] Design an AI Travel Planning Agent
• [ ] Design a Personal Finance Agent

Medium (6)

• [ ] Design a Code Generation Agent
• [ ] Design a Customer Support Agent
• [ ] Design a Data Analysis Agent
• [ ] Design a Workflow Automation Agent
• [ ] Design a Document Processing Agent
• [ ] Design a Sales Development Agent

Hard (7)

• [ ] Design a Deep Research Agent
• [ ] Design a Multi-Agent Orchestration System
• [ ] Design a Security Monitoring Agent
• [ ] Design an Autonomous Testing Agent
• [ ] Design an AI Content Moderation Agent
• [ ] Design an AI Agent Runtime Platform
• [ ] Design an Agent Execution Standard

Advanced (2)

• [ ] Design a Medical Triage Agent
• [ ] Design an Autonomous Trading Agent

ML System Design

2 problems

Easy (1)

• [ ] Design a Sentiment Analysis System

Medium (1)

• [ ] Design a Spam Detection System

How to use this with the sprint

2. Then LLD — the OOD track, 3–4 problems, because it is a separate interview round you currently have no preparation for.
3. Then Agentic AI — doubles as certification prep and portfolio design practice.
4. Everything else is a lookup table. Do not work it linearly; 300 problems at one hour each is 300 hours, roughly nine times the entire System Design budget.

Related

Uber worked example · claude-cert-ccarp

Definition

System design turns a vague problem ("build Twitter") into a concrete blueprint: what services exist, how they talk, where data lives, and how the system stays fast and available as load grows.

Functional vs Non-Functional Requirements

• Functional — what it does: post a tweet, follow a user, load a feed.
• Non-functional — how well it does it: latency, throughput, availability, consistency, durability, cost, scalability.

Interviews are won on the non-functional side — anyone can list features; the skill is reasoning about trade-offs at scale.

Core concerns you always weigh

The universal trade-off

There is no "best" design, only trade-offs. The classic tension is consistency vs availability (CAP), and more broadly performance vs cost vs complexity. Say the trade-off out loud in interviews.

Interview framework (memorize)

1. Clarify requirements + scope (functional + non-functional)
2. Estimate scale (QPS, storage, bandwidth)
3. Define API + data model
4. High-level design (boxes and arrows)
5. Deep-dive one or two components
6. Identify bottlenecks; scale them (caching, replication/sharding)

Related

horizontal-vs-vertical-scaling · capacity-estimation · relational-databases · caching

The two directions

When to use which

• Vertical — early stage, stateful DBs that are hard to distribute, quick wins.
• Horizontal — anything that must be highly available or grow past one machine.

What horizontal scaling requires

• A load balancer to spread requests across nodes.
• Stateless services where possible (session state pushed to a cache or DB) so any node can serve any request.
• For data: replication (read scaling) and sharding (write/storage scaling).

Related

what-is-system-design · caching · relational-databases · nosql-databases

What you estimate

1. QPS (queries/sec) — read QPS and write QPS separately; reads usually dominate.
2. Storage — bytes/record × records/day × retention.
3. Bandwidth — QPS × payload size.
4. Memory — working set you'd want to cache (often the hot 20%).

Numbers worth memorizing

Latency ladder (Jeff Dean, rounded)

• Memory read: ~100 ns
• SSD read: ~100 µs (1,000× memory)
• Network round trip (same DC): ~500 µs
• Disk seek (HDD): ~10 ms
• Cross-continent round trip: ~150 ms

Worked example — 100M DAU, 10 posts read each

• Reads/day = 100M × 10 = 10⁹ → QPS ≈ 10⁹ / 10⁵ = 10,000 read QPS
• Peak ≈ 2–3× average → plan for ~25k QPS
• If each post ≈ 1 KB → bandwidth ≈ 10k × 1 KB = 10 MB/s

Why it matters

The estimate tells you what to scale: high read QPS → caching + read replicas; high storage → sharding; high write QPS → write-optimized store / queue.

Related

what-is-system-design · caching · horizontal-vs-vertical-scaling

Key properties

• Request/response — client sends a request, server returns a response.
• Stateless — each request is independent; state is carried via cookies, tokens, or server-side sessions.
• Text-based (HTTP/1.1) methods + headers + body.

Anatomy

Request: method + path + headers + optional body Response: status code + headers + optional body

Common methods

Status code families

• 2xx success (200 OK, 201 Created)
• 3xx redirect (301 permanent, 302 temporary, 304 Not Modified)
• 4xx client error (400, 401 unauth, 403 forbidden, 404, 429 too many requests)
• 5xx server error (500, 502, 503, 504)

Versions

• HTTP/1.1 — one request at a time per connection (head-of-line blocking); keep-alive reuses connections.
• HTTP/2 — multiplexing over one connection, header compression.
• HTTP/3 — runs over QUIC (UDP), removes TCP head-of-line blocking.

HTTPS

HTTP + TLS encryption. TLS handshake negotiates keys so traffic is confidential and tamper-evident. Assume HTTPS everywhere.

Related

tcp-ip-stack · what-happens-when-you-visit-google · what-is-system-design

The 4 layers (TCP/IP model)

TCP vs UDP

TCP 3-way handshake

SYN → SYN-ACK → ACK establishes a connection before data flows. Adds a round trip of latency — one reason connection reuse (keep-alive, HTTP/2) matters.

Encapsulation

Data gets wrapped top-down as it goes out and unwrapped bottom-up as it arrives: [Ethernet [ IP [ TCP [ HTTP payload ] ] ] ]

Why it matters for system design

Latency = handshakes + round trips + distance. Fewer round trips (connection pooling, CDNs closer to users, HTTP/2/3) = faster systems.

Related

http · what-happens-when-you-visit-google

The full path

1. URL parse — browser splits scheme (https), host (google.com), path.
2. Cache checks — browser cache → OS cache → check if already resolved.
3. DNS resolution — hostname → IP. Recursive resolver asks root → TLD (.com) → authoritative nameserver. Cached along the way with TTLs.
4. TCP handshake — 3-way SYN/SYN-ACK/ACK to the server IP (port 443).
5. TLS handshake — negotiate keys; server presents certificate; secure channel established.
6. HTTP request — GET / with headers (cookies, user-agent).
7. Server-side — likely hits a load balancer → app server → maybe a cache/DB → returns HTML.
8. Response — status + HTML; often a CDN serves static assets from a nearby edge.
9. Render — browser parses HTML, builds DOM, fetches CSS/JS/images (more requests), paints the page.

What each step reveals

Related

http · tcp-ip-stack · caching · horizontal-vs-vertical-scaling

Core ideas

• Tables with a fixed schema; rows = records, columns = fields.
• Keys — primary key (unique row id), foreign key (link to another table).
• Normalization — remove redundancy by splitting into related tables; join at query time.
• SQL — declarative queries (SELECT ... JOIN ... WHERE).

ACID (the reason to pick SQL)

Strengths vs limits

• ✅ Strong consistency, complex queries/joins, mature tooling.
• ⚠️ Vertical scaling ceiling; horizontal scaling of writes is hard (sharding adds complexity, joins across shards are painful).

Scaling a relational DB

1. Indexes — speed up reads.
2. Read replicas — copy for read scaling (async → eventual consistency on replicas).
3. Caching — offload hot reads.
4. Sharding — partition by key across nodes (last resort; complex).

When to choose

Structured data, transactions, correctness (payments, orders, users). Otherwise consider NoSQL.

Related

database-indexes · nosql-databases · caching · horizontal-vs-vertical-scaling

The problem it solves

Without an index, WHERE email = ? does a full table scan — O(n). An index turns that into ~O(log n) lookups.

How it works

• Most indexes are B+ trees: sorted, balanced, great for equality and range queries (BETWEEN, ORDER BY).
• Hash indexes: O(1) equality lookups, but no range queries.
• The index stores the indexed column(s) + a pointer to the row.

The trade-off

Key concepts

• Primary index — on the primary key (often clustered = table stored in key order).
• Secondary index — on other columns.
• Composite index — multiple columns; order matters (leftmost-prefix rule).
• Covering index — includes all columns a query needs, so the DB never touches the table.

Interview line

"Indexes make reads fast and writes slower. I'd index high-selectivity columns used in WHERE/JOIN/ORDER BY, and watch write-heavy tables for index bloat."

Related

relational-databases · caching · capacity-estimation

Four main types

Why NoSQL scales

• Denormalized — data duplicated so a read hits one place (no joins).
• Partition-friendly — designed to shard across many nodes from day one.
• Often eventually consistent — replicas converge over time.

SQL vs NoSQL

CAP intuition

During a network Partition you must choose: Consistency (reject/wait) or Availability (serve possibly-stale data). Many NoSQL stores pick AP.

Related

relational-databases · caching · what-is-system-design

Why cache

• Cut latency (serve from memory, not disk/DB).
• Reduce load on the database / downstream services.
• Absorb read spikes cheaply.

Same foundation as hardware caching: locality of reference — a small hot subset is accessed repeatedly.

Where caches live (layers)

Caching strategies

Eviction policies

When full, decide what to drop: LRU (least recently used, most common), LFU (least frequently used), FIFO, TTL expiry.

The hard parts

• Invalidation — "one of the two hard things in CS." Stale data if the source changes and the cache doesn't.
• Cache stampede — many misses hammer the DB at once (mitigate: locks, request coalescing, staggered TTLs).
• Hit ratio = hits / (hits + misses). Higher = better; low hit ratio means the cache isn't earning its keep.

Related

relational-databases · what-happens-when-you-visit-google · horizontal-vs-vertical-scaling · capacity-estimation

The mechanism

• Programs need their working set (actively used pages) in RAM.
• If too many processes compete for too little RAM, pages are constantly evicted then immediately needed again → page faults → disk I/O.
• Disk is ~10⁵× slower than RAM, so the CPU stalls waiting; utilization looks high but real work drops toward zero.

Signs

• Very high page-fault / swap rate.
• CPU busy but throughput plummets.
• Adding more concurrent work makes it worse, not better.

Causes

• Working set > available RAM.
• Over-subscribing memory (too many processes / too-large degree of multiprogramming).

Fixes

• Reduce degree of multiprogramming (fewer concurrent processes).
• Add RAM / right-size instances.
• Working-set model and page-fault-frequency control by the OS.
• Better locality so the hot set fits in memory.

Why it's in system-design prep

It's the same idea as a cache with a hit ratio too low to help — when the fast layer can't hold the working set, you pay the slow-path cost on nearly every access. Applies to RAM↔disk, cache↔DB, CDN↔origin.

Related

caching · threads · capacity-estimation

Process vs Thread

Why threads

• Concurrency — handle many requests/tasks at once (e.g. a web server per-request).
• Parallelism — use multiple CPU cores for CPU-bound work.
• Responsiveness — do I/O without blocking the whole program.

Concurrency ≠ Parallelism

• Concurrency — dealing with many things at once (interleaving); possible on one core.
• Parallelism — doing many things at the exact same instant; needs multiple cores.

The dangers (shared state)

• Race condition — result depends on timing of unsynchronized access.
• Deadlock — threads wait on each other's locks forever.
• Fixes: mutexes/locks, atomics, avoid shared mutable state, message passing.

Threads vs async I/O

For I/O-bound work (waiting on network/DB), an event loop / async model (or thread pool) scales better than one thread per connection, which is memory-heavy and can lead to thrashing under load. CPU-bound work wants real threads/processes across cores.

Related

thrashing · caching · what-is-system-design

Why

• Distribute load evenly → higher throughput.
• High availability → route around dead/unhealthy nodes (via health checks).
• Scalability → add/remove servers behind the LB transparently.

Where it sits

Client → DNS → Load Balancer → [Server 1 · Server 2 · Server N] Can operate at L4 (transport — routes by IP/port, fast) or L7 (application — routes by URL/headers/cookies, smarter).

Common algorithms

Key concepts

• Health checks — LB pings servers; stops routing to unhealthy ones.
• Sticky sessions — pin a user to one server (needed if state is local; avoid by keeping servers stateless).
• Redundancy — the LB itself must not be a single-point-of-failure; run active-passive/active-active LBs.

Related

horizontal-vs-vertical-scaling · consistent-hashing · sharding · single-point-of-failure

Source: takeUforward roadmap

The problem it solves

Naive sharding uses server = hash(key) % N. If N changes (add/remove a node), almost every key remaps → massive data movement and cache misses.

How it works

1. Hash servers onto a circular ring (0 … 2³²).
2. Hash each key onto the same ring.
3. A key belongs to the first server clockwise from it.
4. Add/remove a node → only the keys between it and its neighbor move (~1/N of keys).

Virtual nodes

One physical server is placed at many points on the ring (virtual nodes) so load is even and removing a node spreads its keys across many others, not just one.

Where it's used

• Distributed caches (Memcached clients), Cassandra/DynamoDB partitioning
• Load balancers wanting sticky routing
• Any system that must scale nodes without reshuffling everything

Remember

Modulo hashing = remap everything on change. Consistent hashing = remap ~1/N. That's the whole point.

Related

sharding · load-balancing · distributed-caching · data-replication

Source: takeUforward roadmap

Partitioning vs replication

• Sharding (partitioning) — different data on different nodes (scales capacity/writes).
• Replication — same data copied to many nodes (scales reads + availability).
• Real systems do both: each shard is also replicated.

Sharding strategies

The hard parts

• Cross-shard queries / joins — slow, need scatter-gather.
• Rebalancing — moving data when adding shards (consistent-hashing minimizes this).
• Hotspots — a "celebrity" key overloading one shard; pick a good shard key.
• Transactions across shards — need distributed transactions (hard).

Remember

Choose a shard key with high cardinality + even access. A bad shard key is the #1 cause of hotspots.

Related

consistent-hashing · data-replication · relational-databases · nosql-databases

Source: takeUforward roadmap

How it works

• A bit array + k hash functions.
• Insert: hash the item k ways, set those k bits to 1.
• Query: hash k ways; if any bit is 0 → definitely not present. If all 1 → probably present (could be a false positive).

Guarantees

Can't delete items (a bit may be shared) — use a counting Bloom filter if you must.

Why it matters

Skip costly disk/network lookups: check the cheap in-memory filter first. - Cassandra/HBase — avoid reading SSTables that don't contain the key. - Caches/CDNs — "one-hit-wonder" filtering. - Databases, spell-checkers, malicious-URL checks.

Trade-off

Tiny memory + O(k) lookups vs a tunable false-positive rate (more bits / more hashes → fewer false positives).

Related

nosql-databases · nosql-optimization · caching

Source: takeUforward roadmap

Why replicate

• Availability — survive node failure (failover to a replica).
• Read scaling — spread reads across replicas.
• Latency — put copies near users (geo-replication).
• Durability — data survives if one disk dies.

Replication models

Sync vs async

• Synchronous — wait for replicas to ack → strong consistency, higher latency, less available.
• Asynchronous — ack immediately, replicate in background → fast + available, but replicas lag (replication lag → stale reads).

Quorum (leaderless)

With N replicas, if W + R > N, reads and writes overlap → you read the latest write. Tune W/R for consistency vs latency.

Related

sharding · data-consistency · tradeoff-consistency-vs-availability · single-point-of-failure

Source: takeUforward roadmap

B-tree vs LSM-tree

LSM-tree write path

1. Write goes to an in-memory memtable (+ a WAL for durability).
2. When full, memtable is flushed to disk as an immutable SSTable (sorted).
3. Background compaction merges SSTables, drops deleted/old versions.

Read-side optimizations

• Bloom filters — skip SSTables that can't contain the key.
• Sparse indexes — jump near the key within an SSTable.
• Sorted SSTables → efficient range scans.

Other NoSQL optimizations

• Denormalization — store data the way it's read (no joins).
• Partitioning (sharding) + replication built in.
• Tunable consistency (quorums) for latency wins.

Related

nosql-databases · bloom-filters · database-indexes · sharding

Source: takeUforward roadmap

The problem

A normal B-tree index handles one dimension well, but "nearest neighbors" on (lat, lng) is 2D — a naive scan is O(n). Spatial structures fix this.

Core techniques

Why geohash is popular

Turns 2D proximity into a 1D sortable prefix, so you can use a normal index/shard key. Nearby points share prefixes → range scan finds neighbors. (Edge case: points across a cell boundary — query neighboring cells too.)

Where used

Ride-hailing (Uber/Lyft driver matching), food delivery, "restaurants near me," geofencing, proximity notifications.

Related

database-indexes · sharding · nosql-databases

Source: takeUforward roadmap

Two meanings

1. Schema migration — add/change columns, indexes, tables.
2. Data migration — move data to a new database/engine (e.g. SQL → NoSQL, or resharding).

The golden rule: backward compatibility

Old and new code run at the same time during a rollout, so every migration step must work with both. Never make a breaking change in one step.

Expand–contract (parallel change) pattern

1. Expand — add the new column/table (nullable, non-breaking).
2. Migrate + dual-write — write to both old and new; backfill old data in batches.
3. Read from new — switch reads once new is complete and verified.
4. Contract — stop writing old; drop it after a safety window.

Zero-downtime data-store move

Dual-write → backfill → shadow-read & compare → cut over → decommission. Keep a rollback path at every step.

Watch out for

• Locking big tables (long ALTER blocks writes) — use online schema-change tools.
• Backfills hammering the DB — batch + throttle.
• Irreversible steps — always have a rollback.

Related

relational-databases · nosql-databases · sharding · data-replication

Source: InterviewReady (via takeUforward roadmap)

The spectrum (strong → weak)

CAP theorem

During a network Partition, you must choose: - CP — stay consistent, sacrifice availability (reject/wait). - AP — stay available, serve possibly-stale data. No partition → you can have both.

PACELC (the fuller picture)

If Partition → choose A or C; Else (normal ops) → choose Latency or Consistency. Even without failures, strong consistency costs latency.

Practical note

Strong consistency needs coordination (quorums/consensus) → slower. Many systems pick eventual/causal consistency for speed and add app-level fixes (read-your-writes, version vectors).

Related

data-consistency-levels · transaction-isolation-levels · data-replication · tradeoff-consistency-vs-availability

Source: takeUforward roadmap

Client-centric guarantees

Why levels matter

Full strong consistency is expensive. These levels give "good enough" guarantees cheaply for the parts that matter (e.g. a user must see their own comment → read-your-writes), while everything else stays eventually consistent.

Tunable consistency (quorum)

Leaderless stores (Cassandra/Dynamo) let you set per-query levels: ONE, QUORUM, ALL. With W + R > N, you get strong-ish consistency; lower values trade consistency for latency/availability.

Interview framing

"I'd default to eventual consistency for scale, but enforce read-your-writes on the user's own data so the UX never looks broken."

Related

data-consistency · transaction-isolation-levels · data-replication

Source: InterviewReady (via takeUforward roadmap)

The read phenomena (anomalies)

The 4 SQL isolation levels

Higher level → fewer anomalies but more locking/aborts → less throughput.

How it's enforced

• Locking (pessimistic) — shared/exclusive locks.
• MVCC (optimistic) — each txn reads a consistent snapshot (Postgres, MySQL InnoDB).

Interview note

"Most OLTP systems default to Read Committed or Repeatable Read. Use Serializable only where correctness is critical (e.g. money) because it serializes and hurts throughput (tradeoff-throughput-vs-latency)."

Related

relational-databases · data-consistency · threads

Source: InterviewReady (via takeUforward roadmap)

Why use one

• Decoupling — producer & consumer don't need to be up at the same time.
• Buffering / load leveling — absorb traffic spikes; consumers work at their own pace.
• Resilience — if a consumer dies, messages wait; retry later.
• Async work — return to the user fast; do slow work (email, video encode) in background.

Core concepts

• Producer / Consumer, Broker (Kafka, RabbitMQ, SQS).
• Ack — consumer confirms processing; unacked messages get redelivered.
• Delivery semantics: at-most-once, at-least-once (common; requires idempotent consumers), exactly-once (hard/expensive).
• DLQ (dead-letter queue) — messages that repeatedly fail land here.
• Ordering — global order is hard; usually ordered per partition/key.

Queue vs Log

• Queue (RabbitMQ/SQS) — message removed once consumed.
• Log (Kafka) — messages retained; consumers track their own offset; multiple consumers can replay.

Interview note

Reach for a queue whenever work can be done later or a spike must be smoothed. Design consumers to be idempotent (at-least-once means duplicates happen).

Related

publisher-subscriber-model · event-driven-systems · database-as-message-queue · asynchronous-apis

Source: takeUforward roadmap

Pub/Sub vs plain queue

How it works

Publisher → Topic → [Subscriber A · Subscriber B · Subscriber C] The broker (Kafka, Google Pub/Sub, Redis Pub/Sub, SNS) routes by topic. Publishers and subscribers never reference each other → maximum decoupling.

Push vs pull

• Push — broker delivers to subscribers.
• Pull — subscribers poll for messages (Kafka consumers). See tradeoff-pull-vs-push.

Where used

Fan-out notifications, cache invalidation broadcasts, event-driven microservices, activity feeds, real-time updates.

Trade-offs

• ✅ Add new subscribers without touching publishers.
• ⚠️ Harder to trace flow; must handle slow/failed subscribers, duplicates, ordering.

Related

message-queues · event-driven-systems · tradeoff-pull-vs-push

Source: takeUforward roadmap

Request-driven vs event-driven

• Request-driven — Service A calls Service B and waits (synchronous, tight coupling).
• Event-driven — Service A emits OrderPlaced; B, C, D react independently (async, loose coupling).

Key patterns

Benefits

• Decoupling, independent scaling, easy to add new reactions.
• Natural audit log (event history).
• Resilience — consumers catch up after downtime.

Challenges

• Eventual consistency (data-consistency) — state converges, not instant.
• Harder debugging/tracing (needs good observability).
• Idempotency & duplicate handling required.
• Event schema evolution.

Related

message-queues · publisher-subscriber-model · microservices-vs-monoliths · data-consistency

Source: takeUforward roadmap

How it works

• Insert a row per job with status = pending.
• Workers poll: SELECT ... WHERE status='pending' ... FOR UPDATE SKIP LOCKED → mark processing → do work → done.
• SKIP LOCKED lets multiple workers grab different rows without blocking.

Why do it

• Transactional consistency — enqueue the job in the same transaction as your data write (solves the dual-write problem). This is the basis of the Transactional Outbox pattern.
• No extra infrastructure to run.

Limits (why real brokers exist)

• Polling wastes DB resources; adds latency vs push.
• The DB becomes a bottleneck / single-point-of-failure under high throughput.
• No native pub/sub fan-out, partitioning, or replay like Kafka.

Transactional Outbox pattern

Write business data + an outbox event row in one transaction; a separate relay publishes outbox rows to the real broker. Guarantees "event emitted iff data committed."

Interview note

"For low volume or to guarantee atomic enqueue-with-write, a DB-backed queue (outbox) is great. At scale, move to a dedicated broker."

Related

message-queues · event-driven-systems · relational-databases · database-migrations

Source: takeUforward roadmap

Common SPOFs

• A single load balancer, database primary, cache, or message broker.
• A single availability zone / data center.
• A single DNS provider or third-party dependency.

How to remove them

Availability math

Availability is measured in nines: 99.9% ≈ 8.7h down/yr, 99.99% ≈ 52 min/yr. - Series (A depends on B): multiply → availability drops. - Parallel (redundant): failure only if all fail → availability rises.

Interview habit

When you draw a design, point at each box and ask "what if this dies?" Then add redundancy + failover. Don't forget the LB and the DB primary.

Related

cascading-failures · data-replication · load-balancing · service-discovery-heartbeats

Source: takeUforward roadmap

Container vs VM

How it works (Linux primitives)

• Namespaces — isolate what a process can see (PIDs, network, mounts).
• cgroups — limit what it can use (CPU, memory).
• Image — read-only layered filesystem; container = running instance of an image.

Why they matter for system design

• "Works on my machine" solved — same artifact dev → prod.
• Fast, dense scaling — spin up many instances quickly behind a LB.
• Foundation for orchestration — Kubernetes schedules containers, handles health/discovery, self-healing, autoscaling.

Remember

Container = lightweight, portable, kernel-sharing process box. VM = heavyweight, full-OS isolation.

Related

service-discovery-heartbeats · microservices-vs-monoliths · single-point-of-failure

Source: takeUforward roadmap

The problem

Hardcoding IPs breaks when instances scale up/down or move. You need a live "phone book" of healthy instances.

Service discovery models

Flow: instance registers on startup → registry tracks it → clients look it up → instance deregisters on shutdown.

Heartbeats

Instances periodically ping the registry ("I'm alive"). Miss N heartbeats → marked unhealthy and removed from routing. This is how the system routes around failures and avoids sending traffic to dead nodes.

• Push heartbeat — instance reports in.
• Pull health check — registry/LB probes the instance (/health).

Where used

Kubernetes (kubelet + liveness/readiness probes), microservice meshes, LB backends.

Related

single-point-of-failure · cascading-failures · containers · load-balancing

Source: takeUforward roadmap

How the cascade happens

Node dies → its traffic hits the survivors → they slow/overload → retries pile up → more nodes die → total outage. Aggressive client retries make it worse (a retry storm).

Prevention patterns

The three most important

1. Timeouts (don't hang), 2. Circuit breakers (fail fast), 3. Backoff + jitter (no retry storm).

Interview note

"I'd add timeouts and a circuit breaker on every remote call, retries with jittered backoff, and load shedding so a partial failure degrades gracefully instead of cascading."

Related

single-point-of-failure · distributed-rate-limiting · anomaly-detection · caching

Source: takeUforward roadmap

The three pillars of observability

Detection approaches

• Static thresholds — alert if error rate > X%. Simple, but noisy/brittle.
• Statistical — flag values N standard deviations from the mean; moving averages.
• Seasonal/ML-based — learn daily/weekly patterns; flag deviations (traffic is supposed to dip at 3am).

What to watch (the "golden signals")

Latency, Traffic, Errors, Saturation (Google SRE). Track percentiles (p50/p95/p99), not just averages — averages hide the tail that hurts users.

Why it matters

Early detection prevents cascading-failures; feeds autoscaling and alerting. Tools: Prometheus + Grafana, Datadog (ties to your DevOps track: monitoring-logging).

Interview note

"I'd expose the four golden signals per service, alert on p99 latency and error rate, and use anomaly detection on seasonal metrics to cut false alarms."

Related

cascading-failures · single-point-of-failure · distributed-rate-limiting

Source: takeUforward roadmap

Why rate limit

• Prevent abuse / DDoS / scraping.
• Protect backends from overload (load shedding).
• Enforce API plans/quotas and fairness.

Classic algorithms

The distributed challenge

Limits must be enforced globally, but state is spread across many servers/regions. - Centralized store — a shared Redis counter (atomic INCR/Lua). Accurate but adds latency + a dependency. - Local + sync — each node limits locally and periodically reconciles. Faster, approximate. - Clock skew and the consistency vs latency trade-off apply.

Where it lives

Usually at the API gateway / edge, keyed by API key / user / IP.

Related

cascading-failures · api-design · distributed-caching · tradeoff-consistency-vs-availability

Source: InterviewReady (via takeUforward roadmap)

Why distribute

A single cache node hits memory and throughput limits and is a single-point-of-failure. Distributing gives capacity, throughput, and availability.

How data is placed

• Consistent hashing maps keys to nodes so adding/removing a node moves only ~1/N of keys (avoids mass cache misses).
• Replication of hot keys for availability and read scaling.

Deployment patterns

Hard problems (at scale)

• Invalidation & staleness — keeping copies consistent with the DB.
• Hot keys — one popular key overloading a node (mitigate: replicate/split it).
• Cache stampede — many misses hit the DB at once (locks, request coalescing, staggered TTLs).
• Eviction — see cache-replacement-policies. Write path — see cache-write-policies.

Related

caching · content-delivery-networks · consistent-hashing · cache-write-policies · cache-replacement-policies

Source: takeUforward roadmap

Why

• Lower latency — content served from a nearby edge, not a distant origin (distance = round-trip time).
• Offload origin — edges absorb most requests, protecting your servers.
• Availability / DDoS absorption — huge distributed capacity at the edge.

What it caches

• Static — images, CSS, JS, video (classic CDN use).
• Dynamic/edge — increasingly, edge compute and cached API responses.

How content gets to the edge

Uses DNS/anycast to route each user to the nearest/healthiest edge (a form of geo load-balancing).

Cache control

• TTL and HTTP headers (Cache-Control, ETag) decide freshness.
• Invalidation / purge when content changes — the hard part (same staleness problem as any cache).

Interview note

"Serve all static assets via CDN with long TTLs + versioned URLs (cache-busting), keeping the origin for dynamic requests."

Related

caching · distributed-caching · what-happens-when-you-visit-google · load-balancing

Source: takeUforward roadmap

The policies

Pairing with read strategy

• Write-through pairs with read-through / cache-aside → cache stays warm and consistent.
• Write-back great for write-heavy workloads (counters, metrics) where some loss is tolerable.
• Write-around good when written data is rarely read soon.

On a miss (read path recap)

• Cache-aside (lazy) — app loads from DB and populates cache. Most common.
• Read-through — cache library loads from DB itself.

Consistency note

Cache + DB is a distributed write → risk of drift. Mitigate with TTLs, write-through, or explicit invalidation. Dual-write ordering bugs are a classic source of staleness.

Related

caching · cache-replacement-policies · distributed-caching · data-consistency

Source: InterviewReady (via takeUforward roadmap)

Common policies

Smarter variants

• Segmented LRU (SLRU) — two segments: probationary + protected. Items promoted to protected on a second hit → resists one-time scans polluting the cache.
• ARC — adapts between recency (LRU) and frequency (LFU) automatically.
• LRU-K / 2Q — consider the Kth-most-recent access, not just the last.

The problem each solves

• Plain LRU is vulnerable to scans (a big one-time sweep evicts your hot set). SLRU/2Q fix this.
• Plain LFU can keep stale-but-once-popular items forever → use aging/decay.

Interview note

"Default LRU. If workloads have scans or skewed popularity, SLRU or ARC keeps the hit ratio higher."

Related

caching · cache-write-policies · distributed-caching · thrashing

Source: InterviewReady (via takeUforward roadmap)

Comparison

Microservices benefits

• Independent deploy & scale per service.
• Team autonomy; polyglot tech.
• Fault isolation (with circuit breakers).

Microservices costs

• Distributed systems problems: network latency, partial failure, eventual consistency.
• Data: no cross-service joins; each service owns its DB; use events/sagas.
• Ops: needs discovery, gateway, observability, CI/CD, containers/orchestration.

Interview stance

"Start monolith, extract microservices only when scaling or team boundaries demand it. Premature microservices add distributed-systems pain for no benefit." (Monolith-first.)

Related

monolith-migration · event-driven-systems · api-design · containers · service-discovery-heartbeats

Source: takeUforward roadmap

Strangler Fig pattern

Put a proxy/gateway in front of the monolith. Route one capability at a time to a new service; the monolith shrinks as new services grow around it, until it's "strangled" away. 1. Identify a bounded capability (e.g. "payments"). 2. Build it as a new service. 3. Route that traffic to the new service via the proxy. 4. Repeat; retire monolith code as it's replaced.

Splitting the data (the hard part)

• Each service should own its data — but the monolith has one shared DB.
• Techniques: database splitting, dual-write + backfill, event-driven sync, the outbox pattern.
• Expect eventual consistency across services.

How to choose boundaries

Split along business capabilities / bounded contexts (Domain-Driven Design), not technical layers. High-change or independently-scaling areas go first.

Pitfalls

• Splitting too fine ("nano-services") → chatty network calls.
• A distributed monolith — services so coupled they must deploy together (worst of both).

Interview note

"Strangler Fig behind a gateway, split by bounded context, hardest part is decomposing the shared database."

Related

microservices-vs-monoliths · database-migrations · api-design · event-driven-systems

Source: takeUforward roadmap

API styles

REST design principles

• Resource-oriented URLs (/users/123/orders), nouns not verbs.
• Correct HTTP methods & status codes.
• Versioning (/v1/…) so you don't break clients.
• Pagination (cursor > offset for large sets), filtering, sorting.
• Idempotency (esp. for retries — idempotency keys on POST).
• Consistent errors, clear auth (oauth/token-based-auth).

API Gateway (the front door)

Single entry point in front of many services. Handles: routing, rate limiting, auth, TLS termination, request aggregation, caching, logging. Keeps cross-cutting concerns out of each service.

Interview note

"Expose a versioned REST/gRPC contract, put an API gateway in front for auth + rate limiting + routing, and make write endpoints idempotent for safe retries."

Related

asynchronous-apis · http · distributed-rate-limiting · oauth · microservices-vs-monoliths

Source: takeUforward roadmap

Why async

Some work is slow (video encode, report generation, ML inference). Blocking the client wastes connections and risks timeouts/cascading-failures. Async returns fast and does the work via a queue.

Patterns for returning the result

Typical async flow

POST /jobs → 202 + jobId → work goes on a queue → worker processes → result stored → client notified (webhook) or polls GET /jobs/{id}.

Interview note

"For long-running work, accept with 202 and a job id, process off a queue, and return the result via webhook (or WebSocket for real-time). Keep the request path fast."

Related

api-design · message-queues · event-driven-systems · http

Source: takeUforward roadmap

The problem it solves

"Let App X read my Google contacts" — without giving App X your Google password. OAuth issues a scoped, revocable access token instead.

The 4 roles

• Resource Owner — the user.
• Client — the app wanting access.
• Authorization Server — issues tokens (e.g. Google).
• Resource Server — holds the data (e.g. Contacts API).

Authorization Code flow (most common)

1. App redirects user to the auth server.
2. User logs in + consents to scopes.
3. Auth server returns a short-lived authorization code.
4. App exchanges code (+ client secret) for an access token (and refresh token).
5. App calls the API with the access token. (PKCE adds security for mobile/SPA clients.)

Tokens

• Access token — short-lived, sent on each request (often a JWT).
• Refresh token — long-lived, used to get new access tokens without re-login.

OAuth vs OpenID Connect

• OAuth 2.0 = authorization (what you can access).
• OIDC = an identity layer on top (who you are) → adds an ID token. "Log in with…" uses OIDC.

Related

token-based-auth · access-control-lists · api-design · http

Source: takeUforward roadmap

Session vs token

Stateless tokens are why they suit microservices and horizontally scaled, stateless services.

JWT structure

header.payload.signature (base64url). - Header — algorithm/type. - Payload — claims (user id, roles, exp expiry). Readable, not encrypted — never put secrets in it. - Signature — HMAC or RSA over header+payload; proves it wasn't tampered with.

The revocation problem

Because the server keeps no state, you can't easily "log out" a JWT before it expires. Mitigations: - Short-lived access tokens + long-lived refresh tokens. - A denylist of revoked token ids (reintroduces some state). - Rotate signing keys.

Security must-dos

Always HTTPS; short expiry; validate signature + exp + issuer/audience; store safely (httpOnly cookie vs localStorage trade-offs).

Related

oauth · access-control-lists · api-design

Source: InterviewReady (via takeUforward roadmap)

AuthN vs AuthZ

• Authentication — who are you? (login, token)
• Authorization — are you allowed to do this? (permissions)

Access Control List (ACL)

A list attached to each resource naming who can do what: file.txt → {alice: read/write, bob: read}. Fine-grained and per-object, but hard to manage at scale (permissions scattered everywhere).

Models compared

Rule engines

Externalize authorization into a policy engine (e.g. Open Policy Agent) that evaluates rules like allow if user.role == 'admin' AND resource.owner == user.id. Keeps policy out of app code, centrally auditable and changeable.

Interview note

"Default to RBAC for simplicity; add ABAC/rule-engine when decisions depend on attributes/context. ACLs for truly per-object sharing."

Related

oauth · token-based-auth · api-design

Source: InterviewReady (via takeUforward roadmap)

Comparison

Classic example: news feed

• Fan-out on write (push) — when you post, write into every follower's feed. Fast reads, but a celebrity with 100M followers = write storm.
• Fan-out on read (pull) — build the feed when a user opens the app. Cheap writes, heavier reads.
• Hybrid — push for normal users, pull for celebrities. (This is what real systems do.)

When to choose

• Pull — data changes slowly, many clients, simplicity matters.
• Push — chat, live scores, notifications, collaborative editing.

Related

publisher-subscriber-model · asynchronous-apis · caching

Source: InterviewReady (via takeUforward roadmap)

The core idea

Latency drops when the answer is already sitting in fast storage; that costs memory. Save memory and you recompute/refetch → higher latency.

Examples of spending memory to cut latency

The other direction (save memory)

Compression, probabilistic structures, computing on demand, sampling — all trade CPU/latency to shrink footprint.

Interview note

"Given a read-heavy, latency-sensitive path, I'd trade memory for speed — cache + precompute. If storage/cost is the constraint, I'd compute on demand or compress and accept higher latency."

Related

caching · database-indexes · tradeoff-throughput-vs-latency · capacity-estimation

Source: InterviewReady (via takeUforward roadmap)

Definitions

• Latency — how long a single operation takes (measure p50/p95/p99, not the average).
• Throughput — total work per unit time (QPS, records/sec).

Why they conflict

Under heavy load, queues fill → latency climbs even if throughput is maxed (Little's Law: L = λ × W).

The restaurant analogy

Cooking 10 orders at once = more meals/hour (throughput) but each diner waits longer (latency). Cooking one at a time = fast per diner, fewer served.

Interview note

"Latency-critical path (checkout) → minimize batching, add capacity. Bulk/analytics pipeline → batch aggressively for throughput. State the p99 target."

Related

tradeoff-memory-vs-latency · message-queues · capacity-estimation · transaction-isolation-levels

Source: InterviewReady (via takeUforward roadmap)

CAP recap

When the network partitions (nodes can't talk): - CP — refuse/block writes so no one reads stale data. Consistent, but some requests fail. - AP — keep answering with whatever each node has. Available, but data may be stale/divergent.

(No partition → you can have both C and A.)

Which to pick — by domain

Real systems are tunable

Many stores let you choose per operation (quorum levels): a shopping app might use strong consistency for checkout and eventual for the "people also bought" widget.

PACELC extension

Even with no partition (Else), you still trade Latency vs Consistency — strong consistency costs coordination time.

Interview note

"Name the CAP choice explicitly per feature. Default AP for scale/UX, CP where correctness is non-negotiable (money)."

Related

data-consistency · data-consistency-levels · data-replication · tradeoff-latency-vs-accuracy

Source: InterviewReady (via takeUforward roadmap)

The idea

Exact answers may need scanning all data or strong coordination (slow). Approximations use sampling, probabilistic structures, or cached/precomputed values (fast).

Approximation techniques

When approximate is fine (vs not)

• ✅ Fine: view counts, "trending," analytics dashboards, recommendations, autocomplete.
• ❌ Not fine: bank balance, inventory at checkout, billing.

Classic example

YouTube view counts and Twitter follower counts are approximate/eventually consistent at scale — exact real-time counting across shards would be far too slow/expensive.

Interview note

"For non-critical metrics I'd serve approximate/cached values for speed, and reserve exact computation for money/inventory."

Related

bloom-filters · tradeoff-consistency-vs-availability · caching · capacity-estimation

Source: InterviewReady (via takeUforward roadmap)

Decision table

Choose SQL when

Structured, related data with transactional correctness: payments, orders, users, inventory, anything needing joins + strong isolation.

Choose NoSQL when

• Key-value — sessions, caching (Redis).
• Document — flexible/evolving schema (MongoDB).
• Wide-column — massive write volume, time-series (Cassandra).
• Graph — relationship-heavy queries (Neo4j).

Polyglot persistence

Real systems use both — SQL for core transactional data, NoSQL for scale-out/flexible parts. Don't force one store to do everything.

Interview note

"Structured + transactional → SQL. Huge scale, flexible schema, or simple key access → NoSQL. State the access pattern first, then pick."

Related

relational-databases · nosql-databases · nosql-optimization · sharding · data-consistency

Source: InterviewReady (via takeUforward roadmap)

Course hub. Anthropic's official AI Fluency course (Skilljar). One note per lesson; this page is the table of contents and the running summary.

AI Fluency = collaborating with AI in ways that are effective, efficient, ethical, and safe — built on the 4D competencies: Delegation · Description · Discernment · Diligence.

Lessons

Add a row per lesson as notes are prepared.

Course resources

• 📖 ai-fluency-glossary — full key-terminology cheat sheet (4Ds + sub-skills, interaction modes, technical and prompt-engineering vocabulary).

The 4Ds at a glance

Interaction modes, in increasing order of handover: Automation → Augmentation → Agency.

Why this matters

Anthropic's official framework teaches the conceptual foundations that underpin interview-grade AI engineering discussions. Complements hands-on frameworks (LangGraph, RAG architectures) with rigorous fundamentals — and the 4Ds are a clean vocabulary for talking about agent design and human-in-the-loop trade-offs in interviews.

Related Topics

• llm-fundamentals-prompting (AI Eng curriculum)
• rag-architecture
• evals-llm-as-judge

Condensed from the course's key-terminology cheat sheet. Course hub: anthropic-ai-fluency-framework. Original © 2025 Rick Dakan, Joseph Feller & Anthropic, CC BY-NC-SA 4.0.

1. Framework terms

AI Fluency — working with AI systems effectively, efficiently, ethically, and safely. It's skills + knowledge + judgment + values, deliberately framed so it survives model churn.

The 4Ds — the four core competencies: Delegation, Description, Discernment, Diligence.

Each D splits into three sub-skills. The pattern is worth memorizing — Description and Discernment share the same Product / Process / Performance decomposition, which is the single most useful structure on the sheet.

Delegation — who does what

Deciding what humans do, what AI does, and how to split it.

Description — communicating the task

Clearly defining outputs, guiding the process, and specifying how the AI should behave.

Discernment — evaluating critically

Same three lenses, turned on the result instead of the request.

Diligence — using AI responsibly

2. Human–AI interaction modes

The progression is how much of the decision-making you hand over — from "do this" to "here's who you are, go handle it."

3. Technical concepts

• Generative AI — systems that create new content (text, images, code) rather than only analyzing existing data.
• Large language models (LLMs) — generative systems trained on huge text corpora to understand and produce language.
• Claude — Anthropic's family of LLMs.
• Parameters — the learned numerical values that determine how a model processes input and relates pieces of language; modern LLMs have billions.
• Neural networks — layered, interconnected nodes that learn patterns from data through training. Brain-inspired, not brain-equivalent.
• Transformer architecture — the 2017 breakthrough design: processes text sequences in parallel while attending to relationships between words across long passages.
• Scaling laws — empirical observation that performance improves in consistent patterns as models, data, and compute grow. Notably, new capabilities can emerge at scale thresholds without being explicitly programmed.
• Pre-training — the initial phase where the model learns language and world patterns from vast text.
• Fine-tuning — later training that teaches instruction-following, helpfulness, and harm avoidance.
• Context window — how much the model can consider at once (conversation history + shared documents). Model-specific ceiling.
• Hallucination — confidently stating something plausible-sounding but false.
• Knowledge cutoff date — the point beyond which the model has no built-in world knowledge, set by when it was trained.
• Reasoning / thinking models — models built to work step-by-step through complex problems; stronger on tasks needing logical reasoning.
• Temperature — randomness control. Higher = more varied and creative (boiling water); lower = more focused and predictable (ice crystals).
• Retrieval augmented generation (RAG) — connecting a model to external knowledge sources to raise accuracy and cut hallucinations. See rag-architecture.
• Bias — systematic output patterns that unfairly favor or disadvantage groups or perspectives, often inherited from training data.

4. Prompt engineering concepts

• Prompt — everything you give the model: instructions plus any shared documents.
• Prompt engineering — designing effective prompts; clear communication plus AI-specific technique.
• Chain-of-thought prompting — have the model work through a problem step by step, breaking complex tasks into smaller ones.
• Few-shot / n-shot prompting — teach by example; N is how many input→output examples you supply. Shows what you want without long explanation.
• Role / persona definition — specify character, expertise, or communication style. Ranges from general ("as a UX design expert") to specific ("explain it like Feynman").
• Output constraints / formatting — state the format, length, and structure you want up front.
• Think-first approach — explicitly ask for reasoning before the final answer.

Cross-links

Most of the Description and Prompt-Engineering vocabulary is the same idea at two altitudes — the 4Ds give you the why, the prompt techniques give you the how.

• ai-fluency-01-introduction — where the 4Ds are introduced
• rag-architecture · llm-fundamentals-prompting · evals-llm-as-judge

Course: anthropic-ai-fluency-framework · Lesson 1 · ~4 min video + reflection

Learning objectives

• Purpose and structure of the course
• Why AI Fluency matters now
• Key components of the learning journey
• What you'll walk away with

Core idea

The course is about collaboration with AI, not AI as a technology. The goal is a durable framework for working with AI systems — not tips and tricks that expire with the next model release.

AI Fluency = the ability to collaborate with AI in ways that are effective, efficient, ethical, and safe.

Those four adverbs are the whole definition; each one is a separate axis you can fail on.

The 4Ds — core competencies

The framework centers on four competencies. Each gets its own lesson later in the course.

1. Delegation — deciding what to hand to AI, what to keep, and how to split the work.
2. Description — communicating the task to the AI well enough to get what you need.
3. Discernment — evaluating the output (and the process) critically.
4. Diligence — responsibility: verification, transparency, honest attribution of AI-assisted work.

Mnemonic: decide → ask → judge → own.

Course structure

• Each of the 4D competencies, one at a time
• Plus key technical and practical concepts underpinning them
• Hands-on exercises against a live language model throughout

Key takeaways

• Focus is human–AI collaboration, not understanding AI as a technology
• Fluency = effective + efficient + ethical + safe
• The 4Ds: Delegation, Description, Discernment, Diligence
• Skills are meant to outlast any specific model generation
• Requires a shift in how you think about working with AI, not just new tactics

Exercise setup

Course exercises need access to a language model. Claude (free account at claude.ai) is the default in the examples; any chatbot works — the principles are model-agnostic. No paid subscription needed.

Reflection prompts

(Answer these in your own words before moving on.)

• What challenges have you hit working with AI toward a specific outcome? -
• What possibilities for AI collaboration excite you most? -
• What do you hope to gain from this course? -

Related

• anthropic-ai-fluency-framework — course hub
• llm-fundamentals-prompting (AI Eng curriculum)

Course hub. One note per lesson; this page is the table of contents and running summary. Sibling course: anthropic-ai-fluency-framework (AI Fluency / the 4Ds).

Claude Code = an agentic coding tool with direct access to your files, terminal, and codebase. An agent is an LLM operating in a loop, taking actions in its environment to reach a goal.

Lessons

Add a row per lesson as notes are prepared.

Running summary

Surfaces: terminal · VS Code · JetBrains · Claude Desktop · web.

Capabilities: read/understand codebase · edit files across the project · run terminal commands and act on their output · search the web.

Three things to keep in mind: context window is finite (hence strategic search over whole-repo loading) · it asks permission by default · it can make mistakes, so stay in the loop.

The agentic loop: prompt → gather context → act → verify → loop until complete and verifiable. You can add context, interrupt, or steer at any point.

Four mechanics: the loop · context (with automatic compaction at the limit) · tools (when to execute code, chosen by semantic understanding) · permissions (default / auto-accept / plan mode, set in your settings file).

⭐ The core workflow — Explore → Plan → Code → Commit. Plan Mode (Shift+Tab) covers Explore + Plan and is the cheapest place to course-correct, because no code exists yet. Then: explicit success criteria, tools, a trustworthy test suite; and before committing, a subagent code reviewer for unbiased eyes. Repeated issues → save to CLAUDE.md.

Why this matters

Agent mechanics — the LLM-in-a-loop, tool access, context management — are the same concepts that show up in langgraph-nodes and langgraph-edges-routing. This course is the concrete, product-level version of the architecture you'd be asked to design in an interview.

Related Topics

• anthropic-ai-fluency-framework · ai-fluency-glossary
• langchain-vs-langgraph · langgraph-nodes · langgraph-edges-routing

Course: claude-code-course · Lesson 1

Definition

An agentic coding tool that understands your codebase, edits your files, runs commands, and integrates with your existing developer tools.

Available in: terminal · VS Code · JetBrains IDEs · Claude Desktop app · web.

Claude Code vs. Claude.ai

The difference is access, and that access is what makes it an agent rather than a chat window.

The copy-paste round trip is the thing being eliminated: it goes in and does the work itself.

What an AI Agent is

Software that interacts with its environment and performs actions to complete a defined goal.

Mechanically: an LLM operating in a loop, in real time. Agents can be given tools, external services, or even other agents to reach their goal.

The loop is the essential part — a model that answers once is not an agent; a model that acts, observes the result, and decides the next action is.

What it can actually do

• Read and understand the codebase — explain a feature, trace a bug across files.
• Edit files across the project — refactor a function and update every reference to it.
• Run terminal commands — build scripts, tests, package installs; and use the output to decide what to do next.
• Search the web — pull documentation or current API references.

That last clause on terminal commands is the agentic bit: output feeds back into the next decision.

Three concepts for using it well

1. The context window — Claude's working memory. Large, but not unlimited. This is why it's agentic: rather than loading the whole repo, it finds strategic ways to locate answers inside the codebase. See ai-fluency-glossary for the general term.
2. It asks permission — by default it confirms before running commands or making changes. You choose hands-on or hands-off; either way you stay in control.
3. It can make mistakes — it can misread intent, introduce a bug, or over-engineer. Staying in the loop catches these early.

Mapping to the anthropic-ai-fluency-framework: #1 is Delegation (platform awareness),

2 is Diligence (deployment), #3 is why Discernment is non-optional.

Recap

Agentic coding tool: reads the codebase, edits files, runs commands, connects to external tools. Terminal, VS Code, JetBrains, Desktop app, web.

Related

• claude-code-course — course hub
• anthropic-ai-fluency-framework — the 4Ds vocabulary for working with it

Course: claude-code-course · Lesson 2

Claude Code is not a chat app. Four mechanics explain the difference: the agentic loop, context, tools, and permissions.

1. The agentic loop

1. Prompt — you enter a prompt.
2. Gather context — Claude Code calls the model, which returns either text or a tool call for Claude Code to execute.
3. Act — it takes the action: edit a file, run a command.
4. Verify — it checks the result against what your prompt asked for.
5. Loop or finish — if the result satisfies the goal, it stops and waits for your next prompt. If not, it loops back and tries again until the results are complete and verifiable.

prompt → gather context → act → verify ──satisfied?──▶ wait for next prompt
              ▲                            │ no
              └────────────────────────────┘

You're inside the loop, not outside it. At any point you can add context, interrupt, or steer toward the goal. That's the practical difference from firing off a prompt and hoping.

The verify step is what makes it an agent rather than a script: the loop is closed by checking outcomes, not by finishing a fixed list of steps.

2. Context

The context window holds the conversation, file contents, command outputs, and more — everything Claude can store and reference.

When you hit the limit, Claude Code compacts the conversation: it automatically decides what to remove or summarize to bring context back to a usable size. Compaction is lossy by design, so anything critical is worth restating rather than assuming it survived.

3. Tools

Tools are the backbone of how agents work.

Tools let Claude Code decide when to execute code to get closer to finishing a task. It uses semantic understanding to determine when to call a tool and how to interpret the output.

4. Permissions

All configurable in your settings file.

⚠️ Be cautious skipping permissions. Free rein to run commands means a mistake is harder to catch before it happens — the permission prompt is the checkpoint, and removing it removes your last chance to intervene.

Connections

• The loop's verify step is anthropic-ai-fluency-framework's Discernment, automated — but it doesn't replace yours.
• Permission modes are a Delegation dial: how much you hand over, per action type.
• Plan mode is the read-before-write discipline — cheap to run, and it surfaces intent mismatches before any file changes.
• Context + compaction is the concrete version of the context-window entry in ai-fluency-glossary.

Related

• claude-code-01-what-is-claude-code — what it is
• claude-code-course — course hub
• langgraph-edges-routing — the same loop-and-route pattern, built by hand

Course: claude-code-course · Lesson 3 · ⭐ the course's headline takeaway

If you take one thing away from the course, take this workflow.

The failure mode it prevents: jumping straight to "write me this code," which front-loads speed and back-loads course-correction. Every correction after code exists costs more than the same correction before it.

1–2. Explore and Plan → use Plan Mode

The fastest way through the first two steps. In plan mode Claude can't edit files — it only reads, to work out how it would tackle the implementation.

Enter it: press Shift + Tab until "Plan Mode" appears under the text input.

Example prompt:

I need to add WebP conversion to our image upload pipeline. Figure out where in the
pipeline it should happen, whether we need new dependencies, and how to approach it.

Note the shape of that prompt: it states the goal and names the unknowns to resolve (where, what dependencies, what approach) rather than prescribing the answer.

Claude reads the relevant files, runs web searches as needed, and returns a plan. Review it against your criteria; if it misses, ask it to revise specific areas.

This is the best place to course-correct — it's before any code is written.

You can also run the explore subagent outside plan mode when you just want a general summary of the codebase with no intention of changing anything after.

3. Code

Approve the plan and Claude works through the items. You choose auto-accept edits or approve-each-time (see claude-code-02-how-claude-code-works for the permission modes).

Claude troubleshoots before calling a plan finished, but sometimes you'll need to step in. A payoff of Plan Mode: after execution you still hold the context of how you got to the result, which guides Claude's next decisions.

Three things that make this phase smoother:

• Define success criteria. For Claude to be confident in its results it needs to know what "correct" looks like. Make it explicit in the plan.
• Add tools. Tools that serve the goal remove a lot of back-and-forth — e.g. for web UI work, the Claude in Chrome extension lets Claude Code drive a browser tab and test the UI.
• Include a test suite. Something it can continuously validate against; it can write tests for you. ⚠️ Verify the tests are a reliable source of truth first, or you get false positives — a green suite that proves nothing is worse than no suite.

Quick tip: if Claude keeps hitting the same issue, ask it to save the solution to CLAUDE.md. That converts a repeated correction into persistent project context.

4. Commit

1. Test the changes yourself and be happy with them.
2. Run a subagent code reviewer before committing. A subagent gets a fresh pair of eyes — it doesn't carry the bias the main agent picked up during the session.
3. Have Claude generate a commit message in your style.
4. Rinse and repeat.

The bias point is the interesting one: the agent that wrote the code is the worst reviewer of it, for the same reason you don't proofread your own writing well.

Why it works

Each phase produces the input the next one needs — context → measurable plan → verified code → reviewed commit. The plan isn't bureaucracy; it's the success yardstick the loop in claude-code-02-how-claude-code-works verifies against. No plan, no verify step worth much.

In anthropic-ai-fluency-framework terms: Explore/Plan is Description (product + process), Code is Delegation in practice, and Commit is Diligence — you verify and vouch for what you ship.

Related

• claude-code-02-how-claude-code-works · claude-code-01-what-is-claude-code
• claude-code-course — course hub

Course hub. One note per notebook. Sibling hubs: claude-code-course · anthropic-ai-fluency-framework.

Source notebooks now live in the vault at raw/Langchain-V1-Crash-Course-main/updatedlangchain/.

Lessons

Revision — three artifacts, three jobs:

Read the master, then test. Recall beats re-reading — but you need something in there to recall.

Not yet covered: llm_gateway_tutorial.ipynb (58 cells) sits at the repo root, outside updatedlangchain/. Say the word and it gets a note too.

The through-line

Read in order, the seven notebooks tell one story — each layer makes the previous one controllable:

create_agent            ← one call, an agent exists          (L01)
    ↓ what model?
init_chat_model         ← provider as a string               (L02)
    ↓ what can it do?
@tool + bind_tools      ← schema + function; model REQUESTS  (L03)
    ↓ what's the state?
Messages                ← the growing list IS the memory     (L04)
    ↓ what shape is the answer?
with_structured_output  ← parseable, not prose               (L05)
    ↓ how do I control the loop?
middleware=[...]        ← summarization, human-in-the-loop   (L06)
    ↓ how do I make it safe?
guardrails              ← same middleware seam, for safety   (L07)

The one-sentence version: an agent is a model plus tools plus a message list, and middleware is the seam where you get control back.

v1 API cheat sheet

Three ideas worth carrying out of this course

1. The model requests tool calls; it never executes them. .invoke() returns tool_calls, and running them is your job. The whole agent loop is list-append.
2. Descriptions are prompts. Tool docstrings and Pydantic Field(description=...) go to the model as schema. Vague description → vague behaviour.
3. Deterministic before model-based. Cheap regex checks first so blocked requests never reach a paid LLM call. Cost and safety point the same way.

Cross-track links

• claude-code-02-how-claude-code-works — the same agentic loop and context compaction, as a product rather than a library
• ai-fluency-glossary — L07 guardrails are Diligence; L04 system messages are Performance Description
• langchain-vs-langgraph · langgraph-nodes · langgraph-edges-routing — ⚠️ written pre-v1; check for v0.x APIs before trusting them

Related

langchain-v1-course siblings above · claude-code-course · anthropic-ai-fluency-framework

The single file to keep. Complete content from all 7 notebooks, in reading order. Detailed per-lesson notes: langchain-v1-course · 1-page skim: langchain-v1-revision-sheet · recall test: langchain-v1-qa-selftest.

⏰ Retention plan — the point of this note

You learned this on Sun 2026-08-16. Forgetting is fastest in the first 48 hours, so the first two checkpoints matter far more than the later ones.

🔴 Tomorrow's 10-minute drill — do this first, from memory

Close this file. On paper, write:

1. The create_agent call, from memory — all three arguments.
2. The three steps of the tool execution loop.
3. What .invoke() returns on a tool-bound model.
4. trigger vs keep in SummarizationMiddleware.
5. The guardrail ordering rule, and why.

Then check against the sections below. Whatever you couldn't write is your revision list — not the whole course. Re-reading things you already know is how revision time gets wasted.

0. The shape of the whole thing

create_agent            one call, an agent exists              L01
    ↓ which model?
init_chat_model         provider as a string                   L02
    ↓ what can it do?
@tool + bind_tools      schema + function; model REQUESTS      L03
    ↓ what is the state?
Messages                the growing list IS the memory         L04
    ↓ what shape is the answer?
with_structured_output  parseable, not prose                   L05
    ↓ how do I control the loop?
middleware=[...]        summarization, human-in-the-loop       L06
    ↓ how do I make it safe?
guardrails              same middleware seam, for safety       L07

An agent is a model + tools + a message list. middleware is where you take control back.

1. Agents — create_agent

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get the weather for a city."""
    return f"The weather in {city} is sunny."

agent = create_agent(
    model="gpt-5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant."
)

response = agent.invoke({"messages": [{"role": "user", "content": "Weather in New York?"}]})
response["messages"]

• model is a string — no object to construct.
• A plain typed function is a tool. Type hints → argument schema. Docstring → the description the model reads to decide when to call it.
• No AgentExecutor, no chain. This is the biggest v0 → v1 break.
• invoke returns the full message list: your message, the AI message with the tool call, the tool result, the final answer. That list is the agent's state.
• A bare string works too — agent.invoke({"messages": "..."}) — but learn the list form.

2. Models — providers, streaming, batching

from langchain.chat_models import init_chat_model

model = init_chat_model("gpt-4.1")                        # OpenAI
model = init_chat_model("google_genai:gemini-2.5-flash")  # Gemini
model = init_chat_model("groq:qwen/qwen3-32b")            # Groq

Provider classes exist — ChatOpenAI, ChatGoogleGenerativeAI, ChatGroq — use them only for provider-specific control. Auth is env vars (OPENAI_API_KEY, GOOGLE_API_KEY, GROQ_API_KEY), loaded with dotenv.

Why prefer init_chat_model: swapping providers becomes a string edit, not a code change.

model.batch([...], config={"max_concurrency": 5})   # cap parallel calls, avoid rate limits

Batch constraint: requests must be independent. If #2 depends on #1's answer, that's a loop, not a batch.

response.content for invoke; chunk.text for stream.

3. Tools ⭐

A tool = (1) a schema — name, description, argument definitions (often JSON schema) — and (2) a function or coroutine to execute.

from langchain.tools import tool

@tool
def get_weather(location: str) -> str:
    """Get the weather at a location"""
    return f"It's sunny in {location}"

model_with_tools = model.bind_tools([get_weather])   # returns a NEW model, no mutation

⭐ The model requests; it does not execute

response = model_with_tools.invoke("What's the weather like in Boston?")

for tool_call in response.tool_calls:
    print(tool_call['name'])   # get_weather
    print(tool_call['args'])   # {'location': 'Boston'}

.invoke() returns a request and stops. Nothing has run. Executing is your job.

The three-step loop

# 1. Model generates tool calls
messages = [{"role": "user", "content": "What's the weather in Boston?"}]
ai_msg = model_with_tools.invoke(messages)
messages.append(ai_msg)

# 2. Execute tools, collect results
for tool_call in ai_msg.tool_calls:
    tool_result = get_weather.invoke(tool_call)   # pass the WHOLE tool_call
    messages.append(tool_result)

# 3. Feed results back for the final answer
final_response = model_with_tools.invoke(messages)

Pass the entire tool_call, not just args — that's what lets the returned ToolMessage carry the matching tool_call_id.

The agent loop is list-append. create_agent runs exactly this, with a termination check.

4. Messages

Message = Role + Content + Metadata. One standard type across all providers.

from langchain.messages import SystemMessage, HumanMessage, AIMessage, ToolMessage

messages = [
    SystemMessage("You are a poetry expert"),
    HumanMessage("Write a poem on artificial intelligence")
]
response = model.invoke(messages)

Bare string when: single standalone request · no history needed · minimal code.

A longer system message buys control:

SystemMessage("""
You are a senior Python developer with expertise in web frameworks.
Always provide code examples and explain your reasoning.
Be concise but thorough in your explanations.
""")

Metadata:

HumanMessage(content="Hello!", name="alice", id="msg_123")   # name = multi-user, id = tracing
response.usage_metadata                                       # token usage

The model has no memory. History is whatever you pass in — so you can construct an AIMessage yourself and insert it, which is how you restore a conversation from a database.

Tool calls and results:

ai_message = AIMessage(content=[], tool_calls=[{
    "name": "get_weather", "args": {"location": "San Francisco"}, "id": "call_123"}])

tool_message = ToolMessage(content="Sunny, 72°F", tool_call_id="call_123")  # MUST match

⭐ tool_call_id must match the call's id — that's how the model knows which result answers which request, once several tools run in one turn. Note an AIMessage with tool calls can have empty content: the call is the payload.

5. Structured output ⭐

from pydantic import BaseModel, Field

class Movie(BaseModel):
    title: str = Field(description="The title of the movie")
    year: int = Field(description="The year the movie was released")
    director: str = Field(description="The director of the movie")
    rating: float = Field(description="The movie's rating out of 10")

model_with_structure = model.with_structured_output(Movie)
response = model_with_structure.invoke("Provide details about the movie Inception")

⭐ Field(description=...) is a prompt. It's sent to the model as schema — that's how it knows what rating means. Same rule as tool docstrings: vague description, vague extraction, no error raised.

Keep the raw message (token usage, metadata) — otherwise you only get the parsed object:

model.with_structured_output(Movie, include_raw=True)

Nesting and optionals:

class Actor(BaseModel):
    name: str
    role: str

class MovieDetails(BaseModel):
    cast: list[Actor]
    genres: list[str]
    budget: float | None = Field(None, description="Budget in millions USD")

TypedDict descriptions: title: Annotated[str, ..., "The title of the movie"]

On an agent — different parameter, different result key:

agent = create_agent(model="gpt-5", response_format=ContactInfo)
result = agent.invoke({"messages": [...]})
result["structured_response"]     # {'name': 'John Doe', 'email': ..., 'phone': ...}

6. Middleware ⭐

Controls what happens inside the agent:

• Tracking behaviour — logging, analytics, debugging
• Transforming prompts, tool selection, output formatting
• Retries, fallbacks, early termination
• Rate limits, guardrails, PII detection

SummarizationMiddleware — automatic context compaction

from langchain.agents.middleware import SummarizationMiddleware
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model="gpt-4o-mini",
    checkpointer=InMemorySaver(),
    middleware=[SummarizationMiddleware(
        model="gpt-4o-mini",
        trigger=("messages", 10),    # WHEN to compress
        keep=("messages", 4),        # what survives verbatim
    )],
)

fraction is the portable one — re-scales automatically when you change models.

Conversations only accumulate with a thread:

config = {"configurable": {"thread_id": "test-1"}}
agent.invoke({"messages": [HumanMessage(content=q)]}, config)

HumanInTheLoopMiddleware — approval gate

from langchain.agents.middleware import HumanInTheLoopMiddleware

agent = create_agent(
    model="gpt-4o",
    tools=[read_email_tool, send_email_tool],
    checkpointer=InMemorySaver(),          # REQUIRED
    middleware=[HumanInTheLoopMiddleware(interrupt_on={
        "send_email_tool": {"allowed_decisions": ["approve", "edit", "reject"]},
        "read_email_tool": False,           # auto-approve
    })],
)

Per tool, not per agent — reads run free, writes stop for a human.

Resuming — the paused result contains __interrupt__:

from langgraph.types import Command

agent.invoke(Command(resume={"decisions": [{"type": "approve"}]}), config=config)
agent.invoke(Command(resume={"decisions": [{"type": "reject"}]}), config=config)

agent.invoke(Command(resume={"decisions": [{
    "type": "edit",
    "edited_action": {"name": "send_email_tool", "args": {
        "recipient": "correct@email.com",
        "subject": "Corrected Subject",
        "body": "This was edited by human before sending"}}
}]}), config=config)

⭐ Two hard requirements: a checkpointer (no persisted state → nothing to resume into), and resuming on the same thread_id (a different one starts a fresh conversation).

edit is the interesting decision — the human rewrites the args and then it executes. Correction, not just veto.

7. Guardrails ⭐

Guardrails ARE middleware. No separate API — middleware=[] in create_agent(). They intercept before the agent, after it, and around model and tool calls.

Two approaches

⭐ Deterministic first, model-based second. Cheap checks run early so blocked requests never reach a paid LLM call. Cost argument as much as a safety one.

PIIMiddleware (built-in)

from langchain.agents.middleware import PIIMiddleware

middleware=[
    PIIMiddleware("email", strategy="redact", apply_to_input=True),
    PIIMiddleware("credit_card", strategy="mask", apply_to_input=True),
    PIIMiddleware("api_key", detector=r"sk-[a-zA-Z0-9]{32}", strategy="block",
                  apply_to_input=True),
]

Built-in types: email · credit_card · ip · mac_address · url. Anything else needs a detector regex.

apply_to_input / apply_to_output pick the direction — often both, different strategy each way.

Custom hooks

from langchain.agents.middleware import AgentMiddleware, AgentState, hook_config
from langgraph.runtime import Runtime

class ContentFilterMiddleware(AgentMiddleware):
    def __init__(self, banned_keywords: list[str]):
        super().__init__()
        self.banned_keywords = [kw.lower() for kw in banned_keywords]

    @hook_config(can_jump_to=["end"])          # declares it may short-circuit
    def before_agent(self, state: AgentState, runtime: Runtime):
        content = state["messages"][0].content.lower()
        for kw in self.banned_keywords:
            if kw in content:
                return {"messages": [{"role": "assistant",
                        "content": "I cannot process that request."}],
                        "jump_to": "end"}
        return None            # None = pass through, NOT block

• before_agent — input filter, runs before any LLM cost.
• after_agent — output validation; model-based safety, compliance footers. A small cheap model (gpt-4o-mini, temperature=0) judges the big model's output.
• None means "no opinion", not "block."

Layering — the array order IS the pipeline

User input
  → [1] ContentFilter      deterministic input filter (cheapest, first)
  → [2] PIIMiddleware      redact on input
  → [3] HumanInTheLoop     approval for sensitive tools
  → [4] PIIMiddleware      redact on output
  → [5] SafetyGuardrail    model-based output safety (most expensive, last)
  → User response

Healthcare worked example: block off-topic/harmful topics (returning a crisis-line message, not a bare refusal), redact patient PII, require approval before booking, append a medical disclaimer in after_agent. The disclaimer trick generalises to any compliance footer.

The 10 things that actually matter

1. The model requests tool calls; it never executes them.
2. The agent loop is list-append — ends when no tool calls remain.
3. Descriptions are prompts — docstrings and Field(description=) go to the model.
4. create_agent is the whole API.
5. init_chat_model("provider:model") makes provider swaps a string edit.
6. Streaming = UX; batching = real speed (independent requests only).
7. tool_call_id must match the call it answers.
8. The model has no memory — history is what you pass in.
9. Middleware is the control seam — summarization, HITL, guardrails all live there.
10. Deterministic before model-based, always.

Related

langchain-v1-course (per-lesson detail) · langchain-v1-revision-sheet (1-page skim) · langchain-v1-qa-selftest (recall) · claude-code-02-how-claude-code-works · ai-fluency-glossary

Course: langchain-v1-course · every topic, condensed to one page. Read top to bottom in ~15 minutes. Self-test version: langchain-v1-qa-selftest.

The whole course in one diagram

create_agent            one call, an agent exists              L01
    ↓ which model?
init_chat_model         provider as a string                   L02
    ↓ what can it do?
@tool + bind_tools      schema + function; model REQUESTS      L03
    ↓ what is the state?
Messages                the growing list IS the memory         L04
    ↓ what shape is the answer?
with_structured_output  parseable, not prose                   L05
    ↓ how do I control the loop?
middleware=[...]        summarization, human-in-the-loop       L06
    ↓ how do I make it safe?
guardrails              same middleware seam, for safety       L07

One sentence: an agent is a model + tools + a message list, and middleware is the seam where you take control back.

Master API table

L01 · Agents

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get the weather for a city."""      # ← this docstring is a PROMPT
    return f"The weather in {city} is sunny."

agent = create_agent(model="gpt-5", tools=[get_weather],
                     system_prompt="You are a helpful assistant.")

response = agent.invoke({"messages": [{"role": "user", "content": "Weather in NY?"}]})

• model is a string. No model object needed.
• A plain typed function is a tool — hints give the args, docstring gives the description.
• No AgentExecutor, no chain to build. That's the v0 → v1 break.
• invoke returns the full message list, not just an answer.

L02 · Models

from langchain.chat_models import init_chat_model
init_chat_model("gpt-4.1")                        # OpenAI
init_chat_model("google_genai:gemini-2.5-flash")  # Gemini
init_chat_model("groq:qwen/qwen3-32b")            # Groq

Provider classes exist too (ChatOpenAI, ChatGoogleGenerativeAI, ChatGroq) — use them only when you need provider-specific control. Auth = env vars.

config={"max_concurrency": 5} caps parallel calls on batch.

L03 · Tools ⭐

Tool = schema (name, description, args) + function to execute.

from langchain.tools import tool

@tool
def get_weather(location: str) -> str:
    """Get the weather at a location"""
    return f"It's sunny in {location}"

model_with_tools = model.bind_tools([get_weather])   # returns a NEW model

⭐ The model requests; it does not execute

.invoke() returns response.tool_calls — name + args — and stops. Nothing has run.

messages = [{"role": "user", "content": "What's the weather in Boston?"}]
ai_msg = model_with_tools.invoke(messages)        # 1. model generates tool calls
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:               # 2. YOU execute
    messages.append(get_weather.invoke(tool_call))  # pass the WHOLE tool_call

final = model_with_tools.invoke(messages)         # 3. feed results back

The agent loop is list-append. Repeat until the model stops emitting tool calls.

L04 · Messages

Message = Role + Content + Metadata. One standard type across all providers.

messages = [SystemMessage("You are a poetry expert"),
            HumanMessage("Write a poem on AI")]

• Bare string prompt: fine for one-shot, no history, minimal code.
• HumanMessage(content=, name=, id=) — name for multi-user, id for tracing.
• response.usage_metadata → token usage.
• ⭐ ToolMessage(tool_call_id=...) must match the AI message's call id — that pairing is how the model knows which result answers which request.
• An AIMessage with tool calls can have empty content — the call is the payload.
• The model has no memory. History is entirely what you pass in; you can fake an AIMessage to restore a conversation from a DB.

L05 · Structured output ⭐

class Movie(BaseModel):
    title: str = Field(description="The title of the movie")   # ← also a PROMPT
    year: int = Field(description="The year it was released")

model.with_structured_output(Movie)                  # parsed object only
model.with_structured_output(Movie, include_raw=True) # + raw msg (usage, metadata)

• Nesting: cast: list[Actor] · Optional: budget: float | None = Field(None, ...)
• TypedDict descriptions: title: Annotated[str, ..., "The title"]
• On an agent: create_agent(response_format=Schema) → result["structured_response"]. All three schema styles work identically.

⭐ Descriptions are prompts, not docs. Same rule as tool docstrings — vague description, vague extraction, no error.

L06 · Middleware ⭐

Controls what happens inside the agent: logging/debugging · transforming prompts, tool selection, output · retries, fallbacks, early termination · rate limits, guardrails, PII.

SummarizationMiddleware — context compaction

SummarizationMiddleware(model="gpt-4o-mini",
                        trigger=("messages", 10),   # WHEN to compress
                        keep=("messages", 4))       # what survives verbatim

Units: messages (count) · tokens (absolute) · fraction (share of context window). fraction is the portable one — re-scales when you change models.

Conversations accumulate only with config={"configurable": {"thread_id": "test-1"}}.

HumanInTheLoopMiddleware — approval gate

HumanInTheLoopMiddleware(interrupt_on={
    "send_email_tool": {"allowed_decisions": ["approve", "edit", "reject"]},
    "read_email_tool": False,        # auto-approve
})

• Per tool, not per agent — reads run free, writes stop for a human.
• ⭐ Requires a checkpointer (InMemorySaver() in dev) — no persisted state, nothing to resume into.
• Resume on the same thread_id, else you start a fresh conversation.
• Paused result contains __interrupt__.
• edit is the notable decision: human rewrites the args via edited_action, then it runs. Correction, not just veto.

L07 · Guardrails ⭐

Guardrails ARE middleware — no separate API. They intercept before the agent, after it, and around model/tool calls.

⭐ Deterministic first, model-based second — blocked requests never reach a paid call. Cost argument as much as a safety one.

PIIMiddleware

PIIMiddleware("email", strategy="redact", apply_to_input=True)
PIIMiddleware("api_key", detector=r"sk-[a-zA-Z0-9]{32}", strategy="block")

Types: email credit_card ip mac_address url — anything else needs a detector regex. Strategies: redact → [REDACTED_EMAIL] · mask → ****-1234 · hash · block (raises).

Custom hooks

class ContentFilterMiddleware(AgentMiddleware):
    @hook_config(can_jump_to=["end"])          # declares it may short-circuit
    def before_agent(self, state, runtime):
        ...
        return {"messages": [...], "jump_to": "end"}   # abort
        return None                                     # pass through

• before_agent = input filter, runs before any LLM cost.
• after_agent = output validation — model-based safety, compliance footers.
• None means "no opinion", not "block".
• Output safety uses a small cheap model as judge (gpt-4o-mini, temperature=0).

Layering — order IS the pipeline

input → [1] content filter (deterministic) → [2] PII in → [3] HITL
      → [4] PII out → [5] model-based safety → user

Cheapest and most certain first; expensive and probabilistic last.

The 10 things that actually matter

1. The model requests tool calls; it never executes them. You run them.
2. The agent loop is list-append — messages grows, loop ends when no tool calls remain.
3. Descriptions are prompts — docstrings and Field(description=) go to the model.
4. create_agent is the whole API — model string, tools, system prompt.
5. init_chat_model("provider:model") makes provider swaps a string edit.
6. Streaming = UX; batching = actual speed (independent requests only).
7. tool_call_id must match the call it answers.
8. The model has no memory — history is whatever you pass in.
9. Middleware is the control seam — summarization, HITL, guardrails all live there.
10. Deterministic before model-based, always.

Cross-track

• claude-code-02-how-claude-code-works — same agentic loop + context compaction, as a product
• ai-fluency-glossary — L07 guardrails = Diligence; L04 system messages = Performance Description
• ⚠️ langchain-vs-langgraph · langgraph-nodes · langgraph-edges-routing — predate v1, may document v0.x APIs

Related

langchain-v1-course · langchain-v1-qa-selftest

Course: langchain-v1-course · 60 questions across all 7 lessons

1. Agents (langchain-v1-01-agents-intro)

Q1.1 — What single function builds an agent in v1, and what are its three main arguments?

Q1.2 — Do you need the @tool decorator to pass a function to create_agent?

Q1.3 — Why is a tool's docstring not just documentation?

Q1.4 — What does agent.invoke({"messages": [...]}) return?

Q1.5 — Name one v0.x concept that no longer appears in this API.

2. Models (langchain-v1-02-model-integration)

Q2.1 — Two ways to get a model. Which is preferred and why?

Q2.2 — Write the init_chat_model string for Gemini 2.5 Flash and for Groq's Qwen3-32B.

Q2.3 — Does streaming make generation faster?

Q2.4 — Does batching make things faster?

Q2.5 — What's the one hard constraint on batch()?

Q2.6 — How do you stop batch() from tripping rate limits?

3. Tools (langchain-v1-03-tools) ⭐

Q3.1 — A tool is a pairing of what two things?

Q3.2 — What does model.bind_tools([get_weather]) return?

Q3.3 — ⭐ After model_with_tools.invoke("What's the weather in Boston?"), has the weather tool run?

Q3.4 — Write the three steps of the tool execution loop.

Q3.5 — Why get_weather.invoke(tool_call) rather than get_weather.invoke(tool_call["args"])?

Q3.6 — In one sentence, what is the agent loop mechanically?

Q3.7 — Which fields do you read off a tool_call?

4. Messages (langchain-v1-04-messages)

Q4.1 — Three parts of every message?

Q4.2 — Name the four message types and what each is for.

Q4.3 — When is a bare string prompt the right choice?

Q4.4 — ⭐ What must tool_call_id on a ToolMessage match, and why does it matter?

Q4.5 — Can an AIMessage carrying tool calls have empty content?

Q4.6 — How do you restore a prior conversation from a database?

5. Structured output (langchain-v1-05-structured-output) ⭐

Q5.1 — Three schema styles, and when you'd pick each.

Q5.2 — ⭐ What is Field(description="...") actually doing?

Q5.3 — What does with_structured_output(Movie) return, and what do you lose?

Q5.4 — How do you get both the parsed object and the raw message?

Q5.5 — Structured output on an agent: which parameter, and where does the result land?

Q5.6 — How do you add descriptions to a TypedDict field?

Q5.7 — How do nested models and optional fields look in Pydantic?

6. Middleware (langchain-v1-06-middleware) ⭐

Q6.1 — What is middleware for? Name the four jobs.

Q6.2 — In SummarizationMiddleware, what do trigger and keep mean?

Q6.3 — Three units they accept — and which is most portable?

Q6.4 — What does a conversation need in order to accumulate across calls?

Q6.5 — ⭐ Two things HumanInTheLoopMiddleware requires to work at all.

Q6.6 — Is human approval configured per agent or per tool? Show the shape.

Q6.7 — The three decisions, and which one is most interesting?

7. Guardrails (langchain-v1-07-guardrails) ⭐

Q7.1 — Where does the guardrails API live?

Q7.2 — Deterministic vs model-based: trade-offs?

Q7.3 — ⭐ State the ordering rule and the reason behind it.

Q7.4 — Four PIIMiddleware strategies and what each produces.

Q7.5 — Built-in PII types? How do you detect something not on the list?

Q7.6 — In a custom hook, what does returning None mean vs returning a dict?

Q7.7 — What does @hook_config(can_jump_to=["end"]) declare?

Q7.8 — Why order the 5-layer stack the way the notebook does?

8. Code-completion drills

Write these from memory before expanding. Getting the shape right matters more than exact punctuation.

Q8.1 — An agent with one tool and a system prompt.

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get the weather for a city."""
    return f"The weather in {city} is sunny."

agent = create_agent(
    model="gpt-5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant."
)

Q8.2 — The full manual tool execution loop.

messages = [{"role": "user", "content": "What's the weather in Boston?"}]
ai_msg = model_with_tools.invoke(messages)
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:
    tool_result = get_weather.invoke(tool_call)
    messages.append(tool_result)

final_response = model_with_tools.invoke(messages)

Q8.3 — A Pydantic schema and structured extraction from a model.

from pydantic import BaseModel, Field

class Movie(BaseModel):
    title: str = Field(description="The title of the movie")
    year: int = Field(description="The year the movie was released")

model_with_structure = model.with_structured_output(Movie)
response = model_with_structure.invoke("Provide details about the movie Inception")

Q8.4 — An agent that summarizes at 10 messages and keeps the last 4.

from langchain.agents.middleware import SummarizationMiddleware
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model="gpt-4o-mini",
    checkpointer=InMemorySaver(),
    middleware=[SummarizationMiddleware(
        model="gpt-4o-mini",
        trigger=("messages", 10),
        keep=("messages", 4),
    )],
)

Q8.5 — Pause on send_email, auto-approve search_web, then approve.

from langchain.agents.middleware import HumanInTheLoopMiddleware
from langgraph.types import Command

agent = create_agent(
    model="gpt-4o",
    tools=[search_web, send_email],
    middleware=[HumanInTheLoopMiddleware(
        interrupt_on={"send_email": True, "search_web": False}
    )],
    checkpointer=InMemorySaver(),
)

config = {"configurable": {"thread_id": "session_001"}}
result = agent.invoke({"messages": [...]}, config=config)

if "__interrupt__" in result:
    agent.invoke(Command(resume={"decisions": [{"type": "approve"}]}), config=config)

9. Rapid fire

Ten seconds each, no expanding until you've answered all ten.

Scoring

Missed questions are your revision list. Re-run this in a week; recall decays fastest in the first few days.

Related

langchain-v1-course · claude-code-course · ai-fluency-glossary

Course: langchain-v1-course · Notebook 1

The whole API in one call

v1's headline: building an agent is one function, create_agent.

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get the weather for a city."""
    return f"The weather in {city} is sunny."

agent = create_agent(
    model="gpt-5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant."
)

Three things to notice:

1. model is a string. No model object to construct — "gpt-5" is enough. See langchain-v1-02-model-integration for the provider-prefixed form.
2. A plain Python function is a tool. No @tool decorator needed here. The type hints and the docstring are the schema — city: str becomes the argument spec and the docstring becomes the description the model reads to decide when to call it.
3. No chain, no executor, no AgentExecutor. If you learned v0.x, this is the part that changed most.

The docstring is not a comment — it's the tool description sent to the model. A vague docstring is a vague tool.

Invoking

State is a messages dict:

response = agent.invoke(
    {"messages": [{"role": "user", "content": "What is the weather like in New York?"}]}
)
response["messages"]

A bare string also works — agent.invoke({"messages": "What is the weather in New York"}) — but the list-of-dicts form is the one to internalize, since it's what multi-turn state actually looks like (langchain-v1-04-messages).

The return is the full message list, not just an answer. response["messages"] holds the whole trace: your human message, the AI message containing the tool call, the tool result, and the final AI message. That list is the agent's working state.

Connection

This is the agentic loop as a library call: the model decides, a tool runs, the result feeds back, repeat until done. create_agent runs that loop for you — which is exactly what langgraph-edges-routing makes you build by hand.

Related

langchain-v1-course · langchain-v1-03-tools · langchain-v1-04-messages

Course: langchain-v1-course · Notebook 2 · OpenAI · Gemini · Groq

Two ways to get a model

init_chat_model — provider-agnostic, preferred. One import, swap providers by string:

from langchain.chat_models import init_chat_model

model = init_chat_model("gpt-4.1")                       # OpenAI (default)
model = init_chat_model("google_genai:gemini-2.5-flash") # Gemini
model = init_chat_model("groq:qwen/qwen3-32b")           # Groq

Provider classes — explicit, more provider-specific control:

from langchain_openai import ChatOpenAI
from langchain_google_genai import ChatGoogleGenerativeAI
from langchain_groq import ChatGroq

model = ChatOpenAI(model="gpt-4.1")
model = ChatGoogleGenerativeAI(model="gemini-2.5-flash-lite")
model = ChatGroq(model="qwen/qwen3-32b")

The "provider:model" prefix is the whole trick — swapping providers is a string edit, not a code change. That's the practical payoff of LangChain's abstraction layer, and the reason to default to init_chat_model.

Auth is env vars: OPENAI_API_KEY, GOOGLE_API_KEY, GROQ_API_KEY, loaded via dotenv.

Three invocation modes

# Streaming — progressive display
for chunk in model.stream("Write me a 200 words paragraph on AI"):
    print(chunk.text, end="|", flush=True)

# Batch — parallel, with a concurrency cap
model.batch(
    ["Why do parrots have colorful feathers?", "How do airplanes fly?", "What is quantum computing?"],
    config={"max_concurrency": 5}   # limit parallel calls
)

Streaming is a UX fix, not a speed fix — total generation time is the same, but perceived latency drops sharply because output appears immediately.

Batch is a real speed and cost fix — requests process in parallel. The constraint is in the name: the requests must be independent. Anything where request 2 depends on response 1 is a loop, not a batch. max_concurrency is your defence against rate limits.

response.content gets the text off an invoke result; chunk.text off a stream chunk.

Related

langchain-v1-course · langchain-v1-01-agents-intro · langchain-v1-04-messages

Course: langchain-v1-course · Notebook 3 · ⭐ interview-relevant core

What a tool is

A tool is a pairing of (1) a schema — name, description, argument definitions (often JSON schema) — and (2) a function or coroutine to execute.

Models can request tool calls to fetch from a database, search the web, or run code. The schema half is what the model sees; the function half is what actually runs.

Defining and binding

from langchain.tools import tool

@tool
def get_weather(location: str) -> str:
    """Get the weather at a location"""
    return f"It's sunny in {location}"

model_with_tools = model.bind_tools([get_weather])

@tool builds the schema from the signature and docstring. bind_tools returns a new model with the tools attached — it doesn't mutate the original.

The model requests; it does not execute

This is the point people miss:

response = model_with_tools.invoke("What's the weather like in Boston?")

for tool_call in response.tool_calls:
    print(f"Tool: {tool_call['name']}")   # get_weather
    print(f"Args: {tool_call['args']}")   # {'location': 'Boston'}

.invoke() returns a request, not a result. The model emits tool_calls — name and args — and stops. Nothing has run. Executing it is your job (or the agent's).

The tool execution loop — three steps

# Step 1: Model generates tool calls
messages = [{"role": "user", "content": "What's the weather in Boston?"}]
ai_msg = model_with_tools.invoke(messages)
messages.append(ai_msg)

# Step 2: Execute tools and collect results
for tool_call in ai_msg.tool_calls:
    tool_result = get_weather.invoke(tool_call)   # pass the whole tool_call
    messages.append(tool_result)

# Step 3: Pass results back to the model for the final response
final_response = model_with_tools.invoke(messages)
print(final_response.text)

Note get_weather.invoke(tool_call) — you pass the entire tool_call object, not just the args. That's what lets the returned ToolMessage carry the matching tool_call_id (langchain-v1-04-messages).

The loop is just list-append. Every step appends to messages; the growing list is the agent's memory. Understand this and create_agent stops being magic — it runs exactly this loop, with a termination check.

Why this matters

This is the mechanical answer to "how does an agent work?" The agentic loop is these three steps, repeated until the model stops emitting tool calls. Being able to write it by hand is the difference between using agents and understanding them.

Related

langchain-v1-course · langchain-v1-04-messages · langgraph-nodes

Course: langchain-v1-course · Notebook 4

Messages are the fundamental unit of context for models in LangChain.

Every message carries three things:

LangChain provides one standard message type across all providers, so behaviour stays consistent regardless of which model you call. That portability is the same promise as init_chat_model in langchain-v1-02-model-integration, one layer down.

The four message types

Text prompt vs message list

A bare string is fine for one-shot work:

model.invoke("what is langchain")

Use text prompts when: single standalone request · no conversation history needed · you want minimal code.

Use message objects when you need roles, history, or tool calls:

from langchain.messages import SystemMessage, HumanMessage

messages = [
    SystemMessage("You are a poetry expert"),
    HumanMessage("Write a poem on artificial intelligence")
]
response = model.invoke(messages)

A longer system message buys you more control — role, format, and verbosity in one place:

system_msg = SystemMessage("""
You are a senior Python developer with expertise in web frameworks.
Always provide code examples and explain your reasoning.
Be concise but thorough in your explanations.
""")

That maps exactly onto Performance Description in ai-fluency-glossary — you're specifying how the model behaves, not just what you want.

Metadata

human_msg = HumanMessage(
    content="Hello!",
    name="alice",   # optional: identify different users
    id="msg_123",   # optional: unique id for tracing
)

response.usage_metadata   # token usage on the response

name matters in multi-user threads; id matters when you're tracing.

Faking history

You can construct an AIMessage yourself and insert it as if the model said it:

ai_msg = AIMessage("I'd be happy to help you with that question!")

messages = [
    SystemMessage("You are a helpful assistant"),
    HumanMessage("Can you help me?"),
    ai_msg,                          # inserted as if it came from the model
    HumanMessage("Great! What's 2+2?")
]

This is how you restore a conversation from a database — the model has no memory of its own, so history is entirely something you supply.

Tool calls and ToolMessage

ai_message = AIMessage(
    content=[],
    tool_calls=[{"name": "get_weather", "args": {"location": "San Francisco"}, "id": "call_123"}]
)

tool_message = ToolMessage(
    content="Sunny, 72°F",
    tool_call_id="call_123"      # MUST match the call id
)

messages = [HumanMessage("What's the weather in San Francisco?"), ai_message, tool_message]
response = model.invoke(messages)

⚠️ tool_call_id must match the id of the call it answers. That pairing is how the model knows which result belongs to which request — essential once several tools are called in one turn. Note also that an AIMessage carrying tool calls can have empty content: the tool call is the payload.

Related

langchain-v1-course · langchain-v1-03-tools · ai-fluency-glossary

Course: langchain-v1-course · Notebook 5 · ⭐ interview-relevant core

Ask the model to answer in a schema so the result is parseable instead of prose. This is the bridge between an LLM and the rest of your program.

Three schema styles

Pydantic

from pydantic import BaseModel, Field

class Movie(BaseModel):
    title: str = Field(description="The title of the movie")
    year: int = Field(description="This year the movie was released")
    director: str = Field(description="The director of the movie")
    rating: float = Field(description="The movies rating out of 10")

model_with_structure = model.with_structured_output(Movie)
response = model_with_structure.invoke("Provide details about the movie Inception")

Field(description=...) is a prompt, not documentation. The descriptions are sent to the model as part of the schema — they're how it knows what rating means. Vague descriptions produce vague extraction.

TypedDict — descriptions via Annotated

from typing_extensions import TypedDict, Annotated

class MovieDict(TypedDict):
    """A movie with details."""
    title: Annotated[str, ..., "The title of the movie"]
    year: Annotated[int, ..., "The year the movie was released"]

Nested structures

Pydantic handles nesting and optionals cleanly:

class Actor(BaseModel):
    name: str
    role: str

class MovieDetails(BaseModel):
    title: str
    year: int
    cast: list[Actor]
    genres: list[str]
    budget: float | None = Field(None, description="Budget in millions USD")

Keeping the raw message

with_structured_output normally returns only the parsed object — you lose token usage and metadata. include_raw=True returns both:

model_with_structure = model.with_structured_output(Movie, include_raw=True)

Worth it whenever you're tracking cost or debugging a bad parse.

Structured output from an agent

On an agent it's response_format instead, and the result lands in structured_response:

from langchain.agents import create_agent

class ContactInfo(BaseModel):
    """Contact information for a person."""
    name: str = Field(description="The name of the person")
    email: str = Field(description="The email address of the person")
    phone: str = Field(description="The phone number of the person")

agent = create_agent(
    model="gpt-5",
    response_format=ContactInfo      # auto-selects ProviderStrategy
)

result = agent.invoke({"messages": [{"role": "user",
    "content": "Extract contact info from: John Doe, john@example.com, (555) 123-4567"}]})

result["structured_response"]
# {'name': 'John Doe', 'email': 'john@example.com', 'phone': '(555) 123-4567'}

All three schema styles work identically here — swap BaseModel for TypedDict or @dataclass and nothing else changes.

Why it matters

Structured output is what makes an LLM a component rather than a chat box — the output feeds a database write, an API call, or a branch in your code. It's also half of the tool schema story in langchain-v1-03-tools: same idea, opposite direction — tools describe inputs the model produces, structured output describes the shape it must answer in.

Related

langchain-v1-course · langchain-v1-03-tools · langchain-v1-01-agents-intro

Course: langchain-v1-course · Notebook 6 · ⭐ interview-relevant core

Middleware provides a way to more tightly control what happens inside the agent.

Four jobs it does:

• Tracking agent behaviour — logging, analytics, debugging
• Transforming prompts, tool selection, output formatting
• Adding retries, fallbacks, early termination
• Applying rate limits, guardrails, PII detection

It's the extensibility seam of v1: create_agent(..., middleware=[...]). Everything in langchain-v1-07-guardrails is built on it.

SummarizationMiddleware

Automatically summarizes conversation history as it approaches token limits — keeping recent messages, compressing older context. For long-running conversations, multi-turn dialogue with big history, and anywhere full context matters.

from langchain.agents.middleware import SummarizationMiddleware
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model="gpt-4o-mini",
    checkpointer=InMemorySaver(),
    middleware=[
        SummarizationMiddleware(
            model="gpt-4o-mini",
            trigger=("messages", 10),   # summarize once history hits 10 messages
            keep=("messages", 4)        # retain the last 4 verbatim
        )
    ]
)

trigger = when to compress · keep = what survives verbatim. Three units, interchangeable: