diff --git a/01. General Prep/authentication_vs_authorization.md b/01. General Prep/authentication_vs_authorization.md
new file mode 100644
index 0000000..37c712f
--- /dev/null
+++ b/01. General Prep/authentication_vs_authorization.md	
@@ -0,0 +1,38 @@
+# Authentication vs Authorization
+
+Authentication and authorization work together to guard access, but they solve different problems:
+
+- **Authentication** answers *“Who are you?”* by verifying identity through credentials such as passwords, tokens, or biometrics.
+- **Authorization** answers *“What are you allowed to do?”* by checking permissions after identity is verified.
+
+## Cheat Sheet
+- AuthN verifies identity; AuthZ checks permissions after identity is known.
+- Mention MFA + secure credential storage as baseline hygiene.
+- Tie authorization back to least privilege with explicit role or policy examples.
+
+## Quick Refresh
+- Confirm you can explain the flow: login → identity established → permission checks.
+- Know common mechanisms: OAuth 2.0, JWTs, sessions, role-based access control (RBAC), attribute-based access control (ABAC).
+- Highlight typical pitfalls: credential leakage, improper session management, over-permissive roles.
+- Keep a simple sequence diagram in mind: user → identity provider → application → resource service.
+
+## Scenario Snapshots
+- **Public marketing site with admin portal:** Anonymous visitors authenticate only when accessing `/admin`; authorization enforces editor vs reviewer roles with fine-grained permissions on content actions.
+- **Multi-tenant SaaS dashboard:** Central identity provider issues tokens containing tenant and role claims. Downstream services authorize requests by validating both tenant ownership and feature entitlements to prevent cross-tenant data leakage.
+- **Internal microservice mesh:** mTLS authenticates services, while sidecar policy engines (e.g., OPA) evaluate authorization rules per endpoint, reducing logic duplication and enabling audit trails.
+
+## Diagram Checklist
+- Use a login flow sequence diagram: `Client → Auth Service → Identity Provider → Token` and return path to `Resource Server`.
+- Include swimlanes for `User`, `App`, `Auth Provider`, and downstream `API` to highlight trust boundaries.
+- Annotate where tokens are issued, stored, refreshed, and validated; call out failure paths (expired token, missing scope).
+
+## Deep Dive Later
+- Compare session-based vs token-based authentication and when to use each.
+- Outline secure password storage (hashing, salting, peppering) and MFA strategies.
+- Explore least privilege design, privilege escalation prevention, and audit logging patterns.
+- Review how cloud providers (AWS IAM, GCP IAM, Azure AD) implement auth/authz flows.
+
+## Interview Prompts
+- Describe an end-to-end login flow for a web app and how you would secure it.
+- Discuss how you would add a new microservice to an ecosystem while reusing existing auth.
+- Explain debugging steps when a user reports unauthorized access or unexpected denial.
diff --git a/01. General Prep/general_questions.md b/01. General Prep/general_questions.md
new file mode 100644
index 0000000..383a83c
--- /dev/null
+++ b/01. General Prep/general_questions.md	
@@ -0,0 +1,18 @@
+# General Interview Questions
+
+Use these prompts to warm up your interview mindset and practice concise storytelling across behavioral and cross-functional topics.
+
+## Cheat Sheet
+- Lead with a tight elevator pitch: current role, top impact, why you’re interviewing.
+- Stockpile 3–4 STAR stories covering leadership, conflict, failure, and big wins.
+- Prepare a closing question bank about team culture, roadmap, and success metrics.
+
+## Quick Refresh
+- Rehearse your introduction, role highlights, and why-now narrative.
+- Skim common behavioral categories: leadership, conflict, failure, collaboration, and impact.
+
+## Deep Dive Later
+- Build full STAR responses for roles, successes, and tough lessons; prioritize metrics and business context.
+
+## Interview Prompts
+- [100 Potential Interview Questions](http://career-advice.monster.com/job-interview/interview-questions/100-potential-interview-questions/article.aspx)
diff --git a/01. General Prep/git.md b/01. General Prep/git.md
new file mode 100644
index 0000000..bfd2a55
--- /dev/null
+++ b/01. General Prep/git.md	
@@ -0,0 +1,62 @@
+# Git Interview Refresh
+
+Keep these branches, cleanup commands, and conceptual contrasts top of mind so you can speak confidently about Git workflows in interviews.
+
+## Cheat Sheet
+- Use `git branch`, `-a`, and `-r` to show scope; know how to target remotes quickly.
+- Explain merge vs rebase with a team workflow example and conflict handling plan.
+- Safely clean the working tree: dry-run `git clean -n` before deleting untracked files.
+
+## Quick Refresh
+- List and filter branches locally and across remotes when walking through repo discovery.
+- Explain how you identify merged versus unmerged branches before cleanup.
+- Know how to delete untracked files safely and when to fall back to selective resets.
+- Contrast merge and rebase to show you can choose the right integration strategy.
+
+## Command Snippets
+
+### Listing branches
+```sh
+# Show local branches and highlight the current one
+git branch
+# Show local and remote branches
+git branch -a
+# Show remote branches only
+git branch -r
+```
+
+### Checking merge status
+```sh
+# Branches already merged into master
+git branch --merged master
+# Branches not yet merged into master
+git branch --no-merged master
+# Remote branches not merged into origin/master
+git branch -r --no-merged origin/master
+```
+
+### Cleaning untracked files
+```sh
+# Dry run: preview files to be removed
+git clean -n
+# Remove untracked files
+git clean -f
+# Remove untracked directories and ignored files
+git clean -d -x -f
+```
+
+### Resetting working tree changes
+```sh
+# Discard changes in a single file
+git checkout -- path/to/file
+# Reset entire working tree to last commit
+git reset --hard
+```
+
+## Interview Prompts
+- Walk through when you would choose merge versus rebase in a team workflow. (See [Atlassian](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).)
+- Explain how you clean up stale feature branches without losing work.
+- Describe your process for recovering from an accidental force push or bad commit.
+
+## Deep Dive Later
+- [Advanced Git Tutorials](https://www.atlassian.com/git/tutorials/advanced-overview) by Atlassian for branching models, hooks, and rebase strategies.
diff --git a/01. General Prep/overview.md b/01. General Prep/overview.md
new file mode 100644
index 0000000..d732815
--- /dev/null
+++ b/01. General Prep/overview.md	
@@ -0,0 +1,7 @@
+# General Prep Overview
+
+**Behavioral Warmup:** Frame your pitch in three beats (role → impact → why now) and recall STAR stories for conflict, failure, and big wins. Quick prompts: [General interview questions](general_questions.md).
+
+**Authentication vs Authorization:** Authentication proves identity (passwords, MFA, SSO); authorization enforces least privilege once identity is confirmed. Visualize login → token → permission check before diving into [Authentication vs Authorization](authentication_vs_authorization.md).
+
+**Git Essentials:** Surface how you list/prune branches, decide between merge vs rebase, and clean untracked files safely (`git clean -n` before `-f`). Reference commands in [Git Interview Refresh](git.md).
diff --git a/02. Web Development/javascript.md b/02. Web Development/javascript.md
new file mode 100644
index 0000000..aef8205
--- /dev/null
+++ b/02. Web Development/javascript.md	
@@ -0,0 +1,23 @@
+# JavaScript Interview Refresh
+
+Focus on browser fundamentals, event handling, and language quirks to keep your JavaScript interviews sharp.
+
+## Cheat Sheet
+- Describe the event loop and microtask queue when explaining async behavior.
+- Know when to use `event.preventDefault()` vs returning `false` in handlers.
+- Share how `"use strict"` impacts `this`, variable declarations, and silent failures.
+
+## Quick Refresh
+- Explain event propagation (capture, target, bubble) and how `event.preventDefault()` differs from returning `false`.
+- Revisit ES modules versus CommonJS and how bundlers/transpilers affect delivery.
+- Recall how `"use strict"` changes scoping, `this` binding, and silent errors.
+
+## Interview Prompts
+- **Preventing form submission:** Compare `event.preventDefault()` with `return false`, discuss when each applies, and describe proper separation of concerns for inline handlers vs. addEventListener.
+- **Async patterns:** Walk through promises, async/await, microtasks vs macrotasks, and the event loop narrative.
+- **State management in the browser:** Outline local/session storage, cookies, and when to leverage IndexedDB.
+
+## Deep Dive Later
+- Read: **event.preventDefault() vs. return false** on [Stack Overflow](http://stackoverflow.com/questions/1357118/).
+- Practice with [16 Great JavaScript Interview Questions](http://www.toptal.com/javascript/interview-questions).
+- Refresh details in [JavaScript "Use Strict"](http://www.w3schools.com/js/js_strict.asp).
diff --git a/02. Web Development/overview.md b/02. Web Development/overview.md
new file mode 100644
index 0000000..6180148
--- /dev/null
+++ b/02. Web Development/overview.md	
@@ -0,0 +1,5 @@
+# Web Development Overview
+
+**HTTP Lifecycle:** Trace DNS → TLS → CDN → app → database to explain latency and scaling decisions. Quick recap: [Web Development Interview Refresh](web_development.md).
+
+**JavaScript Fundamentals:** Revisit the event loop, microtasks vs macrotasks, and `preventDefault()` vs `return false`, including `"use strict"` implications. Details: [JavaScript Interview Refresh](javascript.md).
diff --git a/02. Web Development/web_development.md b/02. Web Development/web_development.md
new file mode 100644
index 0000000..1bb946d
--- /dev/null
+++ b/02. Web Development/web_development.md	
@@ -0,0 +1,28 @@
+# Web Development Interview Refresh
+
+Re-center on fundamental web platform concepts so you can confidently explain request flows, security risks, and modern service communication patterns.
+
+## Cheat Sheet
+- Trace the full HTTP request path including DNS, TLS, CDN, app, and database layers.
+- Define XSS variants and prevention techniques (encode output, CSP, sanitization).
+- Compare REST vs gRPC and note why teams adopt HTTP/2 streaming for microservices.
+
+## Quick Refresh
+- Map the HTTP request lifecycle, including DNS, TLS, proxies, and caching layers.
+- Distinguish between transport (TCP) and application (HTTP) responsibilities.
+- Recall common web security pitfalls such as XSS and how to mitigate them.
+- Summarize service-to-service communication options, including REST and gRPC over HTTP/2.
+
+## Interview Prompts
+- **Explain HTTP vs TCP:** Clarify layering (OSI/Internet stack), reliability, connection management, and how HTTP leverages TCP streams. Be ready to touch on HTTP/2 multiplexing.
+- **What is XSS and how do you prevent it?** Describe reflected, stored, and DOM-based variants. Emphasize output encoding, CSP, input validation, and protected templating systems. Reference real-world examples:
+  - Injected `<script>` via search results that echo raw user input.
+  - Malicious profile data on social platforms leaking session data.
+  - SPA rendering unescaped client-side templates.
+- **How does the web work end-to-end?** Walk through URL entry → DNS resolution → TCP/TLS handshake → HTTP request → load balancer/CDN → application → persistence tiers.
+- **What is gRPC?** Highlight Protocol Buffers, HTTP/2 streaming, contract-first development, and typical use cases inside microservice ecosystems.
+
+## Deep Dive Later
+- [Hypertext Transfer Protocol](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) and [Transmission Control Protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) for protocol internals.
+- [How the web works](http://www.garshol.priv.no/download/text/http-tut.html) and [How the domain name system works](http://wiki.bravenet.com/How_the_domain_name_system_works) for lifecycle walkthroughs.
+- Revisit gRPC guides for auth, load balancing, and code generation best practices.
diff --git a/03. Backend & Frameworks/django.md b/03. Backend & Frameworks/django.md
new file mode 100644
index 0000000..29fbe17
--- /dev/null
+++ b/03. Backend & Frameworks/django.md	
@@ -0,0 +1,21 @@
+# Django Interview Refresh
+
+Keep these ORM patterns and framework concepts handy so you can surface Django-specific depth quickly. Pair this with the [Python interview refresh](python.md) for language fundamentals.
+
+## Cheat Sheet
+- Outline Django’s request flow: URL routing → view → ORM → template → response.
+- Differentiate `select_related` vs `prefetch_related` with a concrete performance example.
+- Mention auth customizations (custom user model, signals, permissions) when discussing security.
+
+## Quick Refresh
+- Explain Django’s MTV (Model-Template-View) architecture and request lifecycle.
+- Contrast `select_related` vs `prefetch_related` and when to apply each for query optimization.
+- Review how Django handles configuration via settings, middleware, and apps.
+
+## Interview Prompts
+- **Query optimization:** Discuss how `select_related` joins foreign keys in a single query while `prefetch_related` performs separate queries suited for many-to-many relationships. Show an example where each shines.
+- **Authentication & authorization:** Outline the default auth system, custom user models, and per-object permissions.
+- **Scaling patterns:** Talk about caching (per-view, per-template, low-level), async support with channels, and background task integration (Celery, RQ).
+
+## Deep Dive Later
+- [select_related vs prefetch_related in Django ORM](https://stackoverflow.com/a/31237071/718722) for nuanced query behavior and performance tips.
diff --git a/03. Backend & Frameworks/java.md b/03. Backend & Frameworks/java.md
new file mode 100644
index 0000000..050e187
--- /dev/null
+++ b/03. Backend & Frameworks/java.md	
@@ -0,0 +1,23 @@
+# Java Interview Refresh
+
+Revisit JVM fundamentals and language features that frequently appear in Java interview conversations.
+
+## Cheat Sheet
+- Explain autoboxing costs and prefer primitives in hot code paths where possible.
+- Summarize how the JVM manages memory (heap regions, GC pauses, tuning levers).
+- Highlight concurrency utilities (executors, CompletableFuture) and how you avoid race conditions.
+
+## Quick Refresh
+- Clarify the difference between primitives and wrapper classes, including autoboxing costs.
+- Review memory management concepts: heap vs stack, garbage collection tuning, escape analysis.
+- Summarize concurrency utilities (executors, futures, completable futures) and best practices.
+
+## Interview Prompts
+- **Autoboxing vs primitives:** Discuss when autoboxing occurs, performance implications, and pitfalls with `==` comparisons.  
+  Reference: [Why do we use autoboxing and unboxing in Java?](http://stackoverflow.com/questions/27647407/why-do-we-use-autoboxing-and-unboxing-in-java)
+- **Collections framework:** Compare `ArrayList`, `LinkedList`, `HashMap`, `TreeMap`, and concurrent variants.
+- **JVM tuning:** Explain how you would diagnose high GC pauses and tools you might use (VisualVM, JFR, profilers).
+
+## Deep Dive Later
+- Refresh Java release highlights (records, sealed classes, pattern matching) relevant to roles you target.
+- Revisit Spring Boot, Micronaut, or Jakarta EE notes if the interview leans toward framework-heavy environments.
diff --git a/03. Backend & Frameworks/overview.md b/03. Backend & Frameworks/overview.md
new file mode 100644
index 0000000..7652865
--- /dev/null
+++ b/03. Backend & Frameworks/overview.md	
@@ -0,0 +1,7 @@
+# Backend & Frameworks Overview
+
+**Python Fundamentals:** Explain GIL impact, mutable vs immutable semantics, and doctest-style validation; see [Python Interview Refresh](python.md).
+
+**Django Patterns:** Show how `select_related`/`prefetch_related` cut query counts, customize auth, and layer caching/async features; review in [Django Interview Refresh](django.md).
+
+**Java Essentials:** Contrast primitives vs wrappers (autoboxing cost), outline JVM memory/GC tuning, and highlight concurrency utilities like `CompletableFuture`; details in [Java Interview Refresh](java.md).
diff --git a/03. Backend & Frameworks/python.md b/03. Backend & Frameworks/python.md
new file mode 100644
index 0000000..9f1632d
--- /dev/null
+++ b/03. Backend & Frameworks/python.md	
@@ -0,0 +1,83 @@
+# Python Interview Refresh
+
+Use this guide to re-ground yourself in Python language fundamentals, runtime characteristics, and coding exercises that often surface in interviews. Also review the dedicated [Django interview refresh](django.md) for framework-specific questions.
+
+## Cheat Sheet
+- Define the GIL impact and when to reach for multiprocessing or async alternatives.
+- Contrast mutable vs immutable types and how that affects function arguments.
+- Explain text vs bytes handling in Python 3 and interoperability with external systems.
+
+## Quick Refresh
+- Explain the Global Interpreter Lock (GIL) and how it affects multithreading in CPython.
+- Differentiate between Python’s core built-in data structures and when to use each.
+- Contrast mutable and immutable types, especially when discussing function arguments and thread safety.
+- Describe how Python handles text (`str`) versus binary (`bytes`) data across versions.
+
+## Interview Prompts
+
+### Global Interpreter Lock (GIL)
+`GIL` is a mutex that prevents multiple native threads from executing Python bytecode simultaneously. It simplifies memory management but limits CPU-bound parallelism in CPython. Review mitigation strategies such as multiprocessing, asyncio, or alternative runtimes.  
+Read: [Global Interpreter Lock](https://wiki.python.org/moin/GlobalInterpreterLock)
+
+### Core Data Types
+- Built-in collections: `dict`, `list`, `set`, `frozenset`, `tuple`.
+- Python 3 uses `str` for Unicode text and `bytes` for binary data (contrast with Python 2’s `str`/`unicode` split).  
+Read: [Python Data Types](https://docs.python.org/3/library/datatypes.html)
+
+### Mutability
+- Immutable examples: numbers, strings, tuples.
+- Mutable examples: dictionaries, lists, sets.  
+Discuss implications for hashing, thread safety, and default arguments.
+
+### Tuple vs List
+Tuples are immutable, lists are mutable. Highlight performance differences, memory usage, and typical use cases (e.g., fixed records vs dynamic collections).
+
+### Sets
+Sets are unordered collections of unique elements implemented with hash tables—great for membership checks and deduplication.  
+Read: [set](https://docs.python.org/2.7/library/stdtypes.html#set)
+
+### Numeric Precision
+Floating-point arithmetic introduces rounding errors (e.g., `0.1 + 0.1 + 0.1 - 0.3`). Demonstrate using `Decimal` for precise calculations.  
+Read: [decimal](https://docs.python.org/3/library/decimal.html)
+
+## Code Drills
+
+### Mutable Default Arguments
+```python
+def append_value(val, items=None):
+    if items is None:
+        items = []
+    items.append(val)
+    return items
+```
+Be ready to explain why the defensive `None` check is necessary and show the buggy version that reuses a shared list.
+
+### Quick Testing with Doctest
+```python
+def my_range(x, y):
+    """
+    >>> my_range(3, 3)
+    []
+    >>> my_range(0, 3)
+    [0, 1, 2]
+    """
+    return list(range(x, y))
+
+if __name__ == "__main__":
+    import doctest
+    doctest.testmod()
+```
+Use this to illustrate lightweight verification and emphasize when to prefer pytest or unittest for complex scenarios.
+
+### Inspecting Source
+```python
+import inspect
+from django.core import context_processors
+
+print(inspect.getsource(context_processors.request))
+```
+Shows how to explore library internals during debugging or interview whiteboarding.
+
+## Deep Dive Later
+- [Iterators](https://wiki.python.org/moin/Iterator) and [Generators](https://wiki.python.org/moin/Generators) for lazy evaluation discussions.
+- [Porting Python 2 Code to Python 3](https://docs.python.org/3/howto/pyporting.html) if legacy migrations surface.
diff --git a/04. Data & Storage/databases.md b/04. Data & Storage/databases.md
new file mode 100644
index 0000000..55c9a7d
--- /dev/null
+++ b/04. Data & Storage/databases.md	
@@ -0,0 +1,35 @@
+# Database Interview Refresh
+
+Reinforce relational storage fundamentals so you can articulate trade-offs, indexing strategies, and engine capabilities in interviews.
+
+## Cheat Sheet
+- Know when to pick transactional engines (InnoDB, PostgreSQL) vs simpler storage (MyISAM).
+- Apply leftmost prefix rules to composite indexes and explain query plan impacts.
+- Discuss tooling for diagnosing slow queries (EXPLAIN, slow query logs, monitoring dashboards).
+
+## Quick Refresh
+- Compare storage engines (e.g., MyISAM vs InnoDB) with respect to transactions, foreign keys, and indexing.
+- Explain how composite indexes work and when additional single-column indexes are still needed.
+- Be ready to describe how you diagnose slow queries using `EXPLAIN`, query plans, or monitoring.
+
+## Comparison Snapshot
+
+| Feature / Use Case | MySQL (InnoDB) | PostgreSQL | MongoDB |
+| --- | --- | --- | --- |
+| **Model** | Relational (row-oriented) | Relational / object-relational | Document (NoSQL) |
+| **Transactions** | ACID with MVCC (InnoDB) | ACID with advanced MVCC | Multi-document ACID (v4.0+), best for single-document |
+| **Joins & Relationships** | Mature join support, foreign keys | Rich joins, foreign keys, advanced query planner | No joins; use embedded docs or `$lookup` aggregation |
+| **Indexes** | B-tree, hash, full-text, spatial (InnoDB) | B-tree, hash, GIN/GiST, BRIN, full-text | B-tree, hashed, geospatial, text |
+| **JSON Support** | `JSON` type (binary), good for hybrid workloads | `JSONB` with indexes and operators | Native document model (BSON) |
+| **Horizontal Scaling** | Primary-replica; sharding via proxy or Vitess | Primary-replica; sharding via Citus/extension | Native sharding and replica sets |
+| **Typical Strengths** | OLTP, read replicas, LAMP stacks | Complex queries, analytics, strict consistency | Flexible schema, rapid iteration, high write scale |
+| **Typical Concerns** | Limited parallel query performance, complex sharding | Operational complexity, tuning vacuum/autovacuum | Requires schema governance, eventual consistency defaults |
+
+## Interview Prompts
+- **Storage engine selection:** MyISAM supports full-text search but lacks transactions and foreign keys. InnoDB offers ACID guarantees, row-level locking, and FK constraints—why does that matter for OLTP workloads?
+- **Composite indexes:** Walk through leftmost prefix rules. Example: With `KEY (name, age, company_name)` you can efficiently query by `name`, `name + age`, or the full composite, but not by `age` alone without another index. Describe how you evaluate index coverage.
+- **Normalization vs denormalization:** Outline when you would introduce redundancy for read performance and how you keep data consistent.
+
+## Deep Dive Later
+- [Partial index](https://en.wikipedia.org/wiki/Partial_index) for targeted indexes on filtered subsets.
+- Review engine-specific documentation (MySQL, PostgreSQL, MongoDB) for features relevant to your upcoming interviews.
diff --git a/04. Data & Storage/overview.md b/04. Data & Storage/overview.md
new file mode 100644
index 0000000..a570357
--- /dev/null
+++ b/04. Data & Storage/overview.md	
@@ -0,0 +1,5 @@
+# Data & Storage Overview
+
+**Engine Selection:** Pick databases based on ACID guarantees, indexing strengths, and OLTP vs analytics fit — check [Database Interview Refresh](databases.md).
+
+**Indexing & Tuning:** Apply leftmost-prefix rules and use `EXPLAIN` plus slow-query logs to tune performance; comparison table and more tips live in [Database Interview Refresh](databases.md).
diff --git a/05. Interview Strategy/algorithms.md b/05. Interview Strategy/algorithms.md
new file mode 100644
index 0000000..20deb7c
--- /dev/null
+++ b/05. Interview Strategy/algorithms.md	
@@ -0,0 +1,60 @@
+# Interview Questions with Algorithmic Tasks
+
+Use this chapter as a conversation prep guide for the algorithm portion of interviews. Keep actual coding drills, deep explanations, and implementations in the dedicated [Algorithms & Data Structures repository](https://github.com/1st/algorithms/). Treat this page as the five-minute reset before a loop or the night-before cram.
+
+**Prep Snapshot:** confirm the interview format, pick one representative pattern to rehearse, note what signal you want to emphasize (communication, trade-offs, testing), and queue up a single follow-up drill in the external repo for later.
+
+## Quick Practice Loop
+- Pick one medium-level problem aligned with the upcoming role; spend 5 minutes clarifying constraints before touching the keyboard.
+- Pseudocode aloud, then solve in your preferred language; timebox to 20 minutes and narrate checkpoints the way you would with the interviewer.
+- Debrief immediately: compare with an editorial/solution, capture new patterns in spaced notes, and flag any follow-up questions.
+- Log or tag the session in the external repo so you can trend common gaps and queue the next drill.
+
+## Cheat Sheet
+- Start answers with complexity targets (`O(n log n)` etc.) and mention trade-offs quickly.
+- Narrate problem-solving steps: clarify, plan, code, test, optimize.
+- Keep a mental map of key data structures (arrays, hash maps, trees, graphs) and go-to patterns.
+- State your assumptions aloud, align on input constraints, and flag potential trade-offs before coding.
+
+## Rapid Memory Joggers
+- Recall quick definitions for time and space complexity (especially `O(1)`, `O(n log n)`, `O(n^2)`) and how you justify them aloud.
+- Rehearse the narrative arc: clarify, plan, code, test, optimize — mention this structure explicitly at the start of the interview.
+- Keep a short list of go-to data structures (arrays, hash maps, stacks/queues, trees/graphs) and the interview prompts where you would reach for each.
+
+## Talking Points by Theme
+
+### Complexity Fundamentals
+- Explain why Big O focuses on growth trends rather than exact timings.
+- Discuss common optimization levers: reducing nested loops, precomputing, leveraging caching.
+
+### Array & String Patterns
+- Outline approaches for sliding window, two pointers, and prefix sums.
+- Share how you'd handle Unicode or streaming input when relevant.
+
+### Hash Map & Set Usage
+- Highlight collision handling (chaining vs open addressing) and typical interview traps (mutable keys, ordering).
+- Describe scenarios where counting or deduplication via hash structures accelerates solutions.
+
+### Tree & Graph Reasoning
+- Summarize DFS vs BFS trade-offs for search and shortest paths.
+- Mention how you keep traversal states (visited sets, recursion stack) and detect cycles.
+
+### Dynamic Programming Narratives
+- Present the “overlapping subproblems + optimal substructure” definition succinctly.
+- Show you can move from recursion to tabulation and reason about memory trade-offs.
+
+## Interview Framing Tips
+- **Clarify first:** Restate the prompt, confirm input format, size limits, data ranges, and edge cases.
+- **Outline aloud:** Share the approach before coding; compare brute force vs optimized strategies and explain the trade-off decision.
+- **Sample walkthrough:** Run through a non-trivial example step by step. Use it to verify your algorithm and catch off-by-one errors.
+- **Complexity statement:** Commit to time/space complexity up front and revisit after coding to confirm.
+- **Coding style:** Use clean variable names, modular helper functions, and narrate what you’re typing.
+- **Testing:** Execute your example plus edge cases (empty, singleton, extremes) verbally. Mention how you’d test in production.
+- **Refinement:** Proactively discuss optimizations, trade-offs, or alternative data structures even if you shipped a working version.
+- **Learning loop:** Tie the outcome back to prior practice — reference similar problems from the [Algorithms & Data Structures repository](https://github.com/1st/algorithms/) and queue deeper drills there instead of here.
+
+## Deep Dive Later
+- Pair each practice session with at least one write-up in your personal notes or the external repo; explain the pattern as if teaching it.
+- Schedule focused coding sessions in the Algorithms & Data Structures repo to reinforce techniques.
+- Capture post-practice reflections there; keep this guide as your high-level conversation map.
+- Study company-specific question patterns and align them to the themes above for targeted prep.
diff --git a/05. Interview Strategy/overview.md b/05. Interview Strategy/overview.md
new file mode 100644
index 0000000..3b49cc5
--- /dev/null
+++ b/05. Interview Strategy/overview.md	
@@ -0,0 +1,7 @@
+# Interview Strategy Overview
+
+**Algorithms Framing:** Lead with complexity targets, narrate clarify → plan → code → test, and map problems to go-to data structures; quick cues in [Interview Questions with Algorithmic Tasks](algorithms.md).
+
+**Behavioral Playbook:** Jump to [Behavioral Interviews](../06.%20Behavioral%20Interviews/overview.md) for STAR storytelling guides and question banks.
+
+**System Design:** Leverage [System Design](../07.%20System%20Design/overview.md) for architectural flows, component deep dives, and glossary refreshers.
diff --git a/06. Behavioral Interviews/behavioral_playbook.md b/06. Behavioral Interviews/behavioral_playbook.md
new file mode 100644
index 0000000..82a8927
--- /dev/null
+++ b/06. Behavioral Interviews/behavioral_playbook.md	
@@ -0,0 +1,48 @@
+# Behavioral Interview Playbook
+
+Use this guide to keep your behavioral answers sharp, structured, and impactful.
+
+## Cheat Sheet
+- Anchor every answer in the STAR arc: Situation → Task → Action → Result.
+- Lead with the headline result before unpacking context.
+- Quantify outcomes and tie them to business impact, not just technical output.
+- Close with reflection: what you learned and how you applied it later.
+
+## Quick Refresh
+- **Situation/Task:** Set the scene in under 15 seconds; name the company, team, and objective or challenge.
+- **Action:** Highlight two or three decisive moves you personally drove. Emphasize collaboration, trade-offs, and leadership behaviors.
+- **Result:** Share measurable impact (metrics, stakeholder sentiment, risk avoided). Mention follow-up iteration or recognition if relevant.
+- **Reflection:** State what you’d do again or differently, and how that lesson shaped future work.
+
+## Story Bank Prompts
+Capture 3–5 versatile stories that can be remixed across multiple question types.
+
+### Leadership & Ownership
+- Took charge of an unclear project and rallied stakeholders.
+- Empowered a teammate or mentored someone to success.
+- Championed a technical or process improvement despite initial resistance.
+
+### Conflict & Collaboration
+- Navigated conflicting priorities with product, design, or infra partners.
+- Mediated a disagreement within the team and reached alignment.
+- Escalated diplomatically when consensus wasn’t possible.
+
+### Failure & Resilience
+- Shipped something that broke or missed expectations; how did you respond?
+- Missed a deadline or lost a customer and rebuilt trust.
+- Took feedback that stung, grew from it, and changed your approach.
+
+### Innovation & Impact
+- Delivered a measurable lift in revenue, retention, latency, or cost savings.
+- Automated or simplified a painful manual workflow.
+- Proposed a trade-off that balanced customer value with engineering capacity.
+
+## Practice Drills
+- Rehearse each story aloud in under two minutes; aim for concise, energetic delivery.
+- Record yourself (audio or video) once per week to spot filler words or missing metrics.
+- Pair each story with 2–3 different question framings (e.g., “biggest challenge,” “difficult stakeholder,” “proud accomplishment”).
+
+## Deep Dive Later
+- Browse company value statements and map your stories to their language.
+- Build a “failure to success” sequence showing growth over multiple roles.
+- Collect testimonials, performance review quotes, or OKR snapshots to keep numbers fresh.
diff --git a/06. Behavioral Interviews/behavioral_questions.md b/06. Behavioral Interviews/behavioral_questions.md
new file mode 100644
index 0000000..5d13fee
--- /dev/null
+++ b/06. Behavioral Interviews/behavioral_questions.md	
@@ -0,0 +1,38 @@
+# Behavioral Interview Question Bank
+
+Use these prompts to explore team dynamics, evaluate fit, and keep conversations two-sided. Tailor them to the company’s product, size, and growth stage.
+
+## Cheat Sheet
+- Prepare 2–3 questions per interviewer (manager, peer engineer, cross-functional partner).
+- Ask about recent wins, upcoming challenges, and how success is measured.
+- Mirror the interviewer’s language to show active listening and alignment.
+
+## Team & Culture
+- How does the team define a successful quarter, and how do you celebrate wins?
+- What does collaboration with product/design/infra look like day to day?
+- How are decisions made when there’s disagreement or ambiguous data?
+- What traits do top performers here share?
+
+## Delivery & Process
+- How do you balance roadmap commitments with unplanned work (bugs, incidents, experiments)?
+- What rituals (standups, demos, postmortems) are most valuable to the team, and why?
+- Describe your release process — what happens before, during, and after a launch?
+- How does the team ensure quality and knowledge sharing as you move quickly?
+
+## Growth & Feedback
+- What opportunities exist for mentorship or technical leadership on this team?
+- How do performance reviews work, and how often do you receive actionable feedback?
+- Can you share a recent example of someone leveling up within the team?
+- How do you invest in onboarding and continued learning?
+
+## Product & Strategy
+- How do you define your target user, and what signal tells you you’re building the right thing?
+- What’s the most important initiative over the next six months, and why?
+- Where does this team’s work intersect with broader company strategy?
+- What metrics or narratives matter most when you pitch new ideas?
+
+## Wrap-Up Prompts
+- Is there anything in my background you’d like me to clarify or expand on?
+- What concerns should I be aware of if I joined tomorrow?
+- What excites you most about the team’s direction right now?
+- What are the next steps in the process, and how can I best prepare?
diff --git a/06. Behavioral Interviews/overview.md b/06. Behavioral Interviews/overview.md
new file mode 100644
index 0000000..ecfbf77
--- /dev/null
+++ b/06. Behavioral Interviews/overview.md	
@@ -0,0 +1,5 @@
+# Behavioral Interviews Overview
+
+**STAR Story Crafting:** Anchor answers in Situation → Task → Action → Result, emphasize impact, and close with reflection; templates in [Behavioral Interview Playbook](behavioral_playbook.md).
+
+**Question Bank:** Prepare thoughtful questions about team culture, delivery cadence, and success metrics with the [Behavioral Interview Question Bank](behavioral_questions.md).
diff --git a/07. System Design/api_gateway.md b/07. System Design/api_gateway.md
new file mode 100644
index 0000000..d3f2208
--- /dev/null
+++ b/07. System Design/api_gateway.md	
@@ -0,0 +1,67 @@
+# API Gateway Deep Dive
+
+Highlight how API gateways centralize cross-cutting concerns, simplify client integrations, and enable rapid iteration across microservices.
+
+## Cheat Sheet
+- **Purpose:** Single entry point that handles routing, authentication, authorization, rate limiting, request/response transformation, observability, and monetization.
+- **Contrast:** Complements (not replaces) load balancers; gateways operate at Layer 7 with business-aware policies, while LBs focus on traffic distribution.
+- **When to introduce:** Multiple clients (web, mobile, partners), numerous backend services, need for consistent auth/policies, or monetized APIs.
+- **Trade-offs:** Added latency, potential bottlenecks, operational complexity, risk of overloading with business logic.
+
+## Quick Refresh
+- **Routing:** Path-based, method-based, header-based routing to different services or versions.
+- **Authentication & Authorization:** JWT validation, OAuth2 flows, API keys, mTLS, custom scopes.
+- **Rate Limiting & Quotas:** Protect downstream services via token buckets, leaky bucket, or fixed window algorithms; support per-client quotas.
+- **Request Transformation:** Rewrite headers, aggregate responses, perform protocol translation (REST ↔ gRPC ↔ SOAP).
+- **Caching & Compression:** Offload response caching or payload compression for frequently accessed endpoints.
+- **Observability:** Centralized logging, tracing, metrics, correlation IDs, and threat detection (WAF).
+
+### Diagram Prep Notes
+1. Entry: client → CDN/WAF → API gateway edge nodes (highlight mTLS termination).
+2. Policy layer: auth, quota, schema validation blocks shown inline.
+3. Routing fan-out: services/BFFs plus async pathways (queues, events) if used.
+4. Telemetry: arrows to logging/metrics/tracing sinks for observability.
+
+## Patterns & Trade-Offs
+
+### API Gateway vs Backend For Frontend (BFF)
+- **Gateway:** One gateway serving multiple clients; central policy engine.
+- **BFF:** Dedicated service per client type (web, mobile) to tailor responses. Reduces payload bloat and client logic but increases service count.
+- **Combination:** Gateway handles auth/rate limiting, then routes to client-specific BFFs.
+
+### Managed vs Self-Hosted
+- **Managed (AWS API Gateway, Apigee, Kong Cloud):** Faster setup, built-in analytics, auto-scaling; less control over customization and cost structure.
+- **Self-hosted (Kong OSS, Tyk, Envoy, NGINX):** Greater flexibility, control over latency and extensions; requires ops expertise.
+- **Decision factors:** Traffic scale, compliance needs, customization, team skill set.
+
+### Security Posture
+- **Threat protection:** WAF rules, bot detection, rate limiting, schema validation.
+- **Zero-trust:** Combine mTLS, JWT verification, and per-route policies.
+- **Secrets:** Rotate API keys/tokens, integrate with secret managers, log access patterns for anomaly detection.
+
+### Versioning & Lifecycle
+- **URL versioning (`/v1/`), header-based, or query-param based** depending on client capabilities.
+- **Graceful deprecations:** Route old clients to legacy adapters, communicate timelines, monitor usage.
+- **Canary releases:** Route a fraction of traffic to new versions using header flags or token targeting.
+
+## Example Anecdotes
+- **Partner integration:** Gateway enforced partner-specific rate limits and analytics, enabling monetized APIs while protecting core services.
+- **gRPC adoption:** Gateway translated external REST calls to internal gRPC, allowing gradual client migration.
+- **Security incident:** Missing auth on an internal endpoint exposed via gateway; incident response added default-deny policies and automated contract tests.
+- **Latency regression:** Custom business logic in the gateway increased latency; refactor pushed heavy computation downstream to microservices.
+
+## Interview Prompts
+- When would you choose an API gateway versus direct service-to-service communication?
+- How do you secure and monitor third-party integrations through the gateway?
+- Explain how you’d handle rolling out a new version of an API while supporting old clients.
+- Discuss strategies for rate limiting noisy clients without harming mission-critical users.
+
+## Deep Dive Later
+- Evaluate gateway offerings (AWS API Gateway, Kong, Apigee, Azure API Management) and pricing models.
+- Prototype a lightweight gateway with Kong or Envoy; experiment with plugins for auth and rate limiting.
+- Study case studies of API monetization and developer portal management for storytelling content.
+
+## Diagram Ideas
+- Request flow diagram: client → API gateway (auth, rate limiting, routing) → multiple microservices/BFFs.
+- Component view: gateway integrating WAF, analytics, developer portal, and service discovery.
+- Deployment topology: managed gateway vs self-hosted cluster with control plane/data plane separation.
diff --git a/07. System Design/caching_strategies.md b/07. System Design/caching_strategies.md
new file mode 100644
index 0000000..518af03
--- /dev/null
+++ b/07. System Design/caching_strategies.md	
@@ -0,0 +1,79 @@
+# Caching Strategies Deep Dive
+
+Explain how caches cut latency and load, manage consistency, and align with product goals.
+
+## Cheat Sheet
+- **Why cache?** Reduce latency, absorb traffic spikes, protect downstream systems, and cut costs.
+- **Layers:** CDN/edge, application cache, database cache, client cache.
+- **Patterns:** Cache-aside, write-through, write-behind, read-through, refresh-ahead.
+- **Pitfalls:** Stale data, thundering herds, cache stampedes, eviction storms.
+
+## Quick Refresh
+- **Cache Selection:** Match technology to access pattern (CDN for static assets, Redis/Memcached for key-value, local memory cache for single-node).
+- **TTL & Eviction:** Set time-to-live based on freshness needs. Understand LRU, LFU, FIFO. Plan for manual invalidation when TTL is too long.
+- **Consistency:** Choose between eventual consistency (cheap, widely used) and strong consistency (complex, often slower). Mention read repair or write fences for critical paths.
+- **Compression & Serialization:** Minimize payload size; weigh CPU cost vs bandwidth savings.
+- **Security:** Avoid caching PII in shared layers. Use cache keys that don’t leak sensitive information.
+
+## Patterns & Trade-Offs
+
+### Cache-Aside (Lazy Loading)
+- Application checks cache first; on miss, fetches from source and populates cache.
+- **Pros:** Simple, avoids stale writes, works with any datastore.
+- **Cons:** Stampedes on cold start or popular keys; mitigate with locking, request coalescing, or jittered TTLs.
+
+### Write-Through
+- Application writes to cache and datastore synchronously.
+- **Pros:** Cache stays warm; good for read-heavy workloads.
+- **Cons:** Adds write latency; failed cache write can complicate error handling.
+
+### Write-Behind (Write-Back)
+- Application writes to cache, then asynchronously persists to datastore.
+- **Pros:** Absorbs bursts, reduces write amplification.
+- **Cons:** Risk of data loss on cache failure; requires durable queues or logs.
+
+### Read-Through
+- Cache layer managed by library/proxy; app always calls cache, which fetches on miss.
+- **Pros:** Centralized logic, consistent behavior.
+- **Cons:** Less control; vendor lock-in or complex frameworks.
+
+### Refresh-Ahead / Prewarming
+- Automatically refresh hot keys before they expire.
+- **Pros:** Smooths latency for known hotspots.
+- **Cons:** Risk of fetching unused keys; need heuristics or ML-based predictions.
+
+## Operational Considerations
+- **Cache Stampede Mitigation:** Use request coalescing, mutex locks, probabilistic early expiration (e.g., dogpile prevention), or tiered caching.
+- **Monitoring:** Track hit rate, eviction rate, latency, resource usage. Alert on sudden drops in hit rate or surge in evictions.
+- **Scaling:** Partition caches by consistent hashing; manage rebalancing carefully to avoid widespread cache misses.
+- **Failure Modes:** Plan for cache cluster outages — fallback to graceful degradation, precomputed responses, or traffic shaping.
+
+## Example Anecdotes
+- **Launch day:** CDN cached static assets, reducing origin load by 90%; missed cache invalidation caused stale hero image — scripted invalidation and added monitoring.
+- **Cache stampede:** Viral content caused DB overload after cache eviction. Added jittered TTL and single-flight locking to prevent duplicate fetches.
+- **Price updates:** Financial app required strong consistency; used write-through caches with short TTL and per-key invalidation hooks.
+- **Session caching:** Redis outage invalidated user sessions. Lesson: combine sticky sessions with durable stores or multi-region cache replication.
+
+## Interview Prompts
+- How would you cache a frequently read but occasionally updated resource? Discuss invalidation and latency expectations.
+- Describe handling a cache miss storm after deploying globally.
+- Explain why caching user-specific data differs from caching canonical reference data.
+- Outline how you’d monitor cache effectiveness and detect regressions.
+
+## Deep Dive Later
+- Experiment with Redis features (Lua scripting, Redis Cluster, streams) or Memcached deployment.
+- Study CDN configurations (CloudFront, Fastly, Akamai) for edge cases like signed URLs and private content.
+- Build a simulation of cache hit/miss patterns using traffic traces to explain cost savings and trade-offs.
+
+## Diagram Ideas
+- Layered cache stack: client cache, CDN, application cache, database cache with arrows showing miss/hit flow.
+- Sequence diagram for cache-aside: request → cache miss → database → cache populate → response.
+- Heat map concept: shard/partition load before and after caching to illustrate hit-rate impact.
+
+### Cache-Aside Flow Outline (for diagram)
+1. Request hits application → checks cache for key.
+2. On miss, fetch data from primary store and validate result.
+3. Write value into cache with TTL plus optional tags/invalidation hooks.
+4. Return response to caller; subsequent requests served from cache until TTL expires or invalidation occurs.
+
+See draft mermaid sequence in `diagrams/cache_read_write_sequence.md` for reference.
diff --git a/07. System Design/data_sharding.md b/07. System Design/data_sharding.md
new file mode 100644
index 0000000..c864680
--- /dev/null
+++ b/07. System Design/data_sharding.md	
@@ -0,0 +1,88 @@
+# Data Sharding & Storage Tiering Deep Dive
+
+Explain how to split and replicate data intelligently to meet growth, latency, and isolation goals.
+
+## Cheat Sheet
+- **Why shard?** Horizontal scale, lower per-node load, regional latency optimization, tenant isolation.
+- **Core decisions:** Shard key choice, partitioning strategy, replication model, rebalancing plan.
+- **Common pitfalls:** Hot partitions, uneven growth, cross-shard joins, complex transactions, operational overhead.
+- **Interview hook:** Share a migration story or incident involving shard rebalancing or tenant isolation.
+
+## Quick Refresh
+- **Partitioning Strategies:** Range, hash, list, composite, directory-based. Mention pros/cons for each.
+- **Replication:** Pair sharding with master/replica, leaderless, or quorum-based models to balance availability and consistency.
+- **Routing:** Application-layer lookup, middleware (shard map), proxy services (e.g., Vitess, Citus).
+- **Metadata:** Maintain consistent shard metadata and automate updates during scaling.
+- **Cross-Shard Operations:** Avoid when possible; use scatter-gather queries or analytic pipelines when necessary.
+- **Multi-Tenancy:** Decide between shared, pooled, or dedicated shards per tenant. Mention noisy neighbor concerns and data residency requirements.
+
+## Partitioning Patterns & Trade-Offs
+
+### Range Sharding
+- **How it works:** Partition data by ordered key ranges (e.g., user ID ranges, timestamps).
+- **Pros:** Efficient range scans, locality-aware caching, good for time-series.
+- **Cons:** Hot spots when recent writes concentrate in one range; requires periodic split or rotation.
+- **Mitigation:** Pre-split ranges, rotate active shards, combine with hash on high-cardinality attributes.
+
+### Hash Sharding
+- **How it works:** Apply hash function to key and distribute uniformly.
+- **Pros:** Even distribution for random access workloads, simple to scale with consistent hashing.
+- **Cons:** Poor range query support, harder to co-locate related data.
+- **Mitigation:** Use consistent hashing rings, virtual nodes to ease rebalancing.
+
+### Directory / Lookup Sharding
+- **How it works:** Maintain a routing table mapping keys/tenants to shards.
+- **Pros:** Flexibility to place large tenants or special workloads on dedicated shards.
+- **Cons:** Metadata service becomes critical dependency; requires strong consistency and failover.
+- **Mitigation:** Replicate directory, cache lookups with TTL, log changes for recovery.
+
+### Geo/Regional Sharding
+- **How it works:** Route users to regional shards (e.g., EU vs US data centers) for compliance and latency.
+- **Pros:** Data residency compliance, lower latency within region.
+- **Cons:** Cross-region coordination for global features, failover complexity.
+- **Mitigation:** Pair with global service mesh, asynchronous replication, or multi-master setups with conflict resolution.
+
+## Rebalancing & Growth
+- **Capacity Planning:** Monitor shard size, QPS, and storage growth. Set thresholds for split/merge operations.
+- **Automated Rebalancing:** Implement tools to migrate data gradually (bulk copy + dual writes + cutover). Consider Vitess, Citus, Spanner-style automation.
+- **Dual Writes & Backfill:** Plan for consistency during migration — copy data, replay binlogs/CDC, verify via checksums.
+- **Tenant Moves:** For SaaS, support moving a tenant between shards with minimal downtime; communicate maintenance windows.
+
+## Isolation & Consistency
+- **Transactions:** Cross-shard transactions are expensive. Use two-phase commit sparingly or design to avoid them.
+- **Joins:** Denormalize or precompute aggregates; use analytical systems for cross-shard queries.
+- **Backups & DR:** Coordinate backups per shard; ensure consistent points in time across replicas.
+- **Security:** Separate encryption keys per shard, enforce access controls for compliance (HIPAA, GDPR).
+
+## Storage Tiering
+- **Hot vs Cold Data:** Keep hot data in primary shards, move cold/archival data to cheaper stores (S3 + query engines).
+- **Hybrid Approaches:** Serve latest data from OLTP shards, historical from OLAP warehouse; combine in APIs via summary tables or asynchronous aggregation.
+- **Lifecycle Policies:** Automate TTL-based movement, compaction, or deletion to control storage costs.
+
+## Example Anecdotes
+- **Shard exhaustion:** User ID hash caused a single large customer to overload one shard. Adopted virtual nodes and tenant-aware routing.
+- **Regional expansion:** Launching in EU required separate shard for GDPR; built async pipeline for cross-region analytics.
+- **Dual-write migration:** Moving from single database to sharded cluster involved CDC stream, replaying backlog, and carefully orchestrated cutover.
+- **Resharding incident:** Manual resharding caused data drift; postmortem drove automated tooling with validation and traffic throttling.
+
+## Interview Prompts
+- How would you shard a fast-growing multi-tenant SaaS product? Which key would you choose and why?
+- What happens when a shard becomes a hot spot, and how do you mitigate it?
+- Describe a zero-downtime approach to migrating data to new shards.
+- How do you handle global reporting requirements when data lives in multiple regional shards?
+
+## Deep Dive Later
+- Explore sharding frameworks (Vitess for MySQL, Citus for PostgreSQL, Cosmos DB, DynamoDB global tables).
+- Study Spanner/CockroachDB for globally-distributed consistency models.
+- Prototype shard-aware services with consistent hashing libraries or proxy layers to build intuition.
+
+## Diagram Ideas
+- Shard map diagram: client → router → shard nodes with replication pairs.
+- Timeline of resharding: copy, dual writes, validation, cutover.
+- Multi-tenant layout: dedicated shards vs pooled shards highlighting noisy neighbor isolation.
+
+### Diagram Prep Notes
+1. Shard map: list shard IDs, primary/replica roles, and routing metadata service.
+2. Resharding timeline: capture phases (split, dual write, verification, cutover) with duration estimates.
+
+See `diagrams/data_sharding_map.md` for the current topology draft.
diff --git a/07. System Design/ddos_playbook.md b/07. System Design/ddos_playbook.md
new file mode 100644
index 0000000..0344ef6
--- /dev/null
+++ b/07. System Design/ddos_playbook.md	
@@ -0,0 +1,47 @@
+# DDoS Response Playbook
+
+A reusable checklist for preparing, detecting, and responding to distributed denial-of-service attacks in production environments.
+
+## Preparation
+- **Architecture:** Route all public traffic through CDN/WAF layers with automatic DDoS scrubbing; restrict direct access to origin/load balancer IPs.
+- **Capacity Planning:** Understand baseline traffic (per region, per endpoint) and establish automated scaling limits for edge providers and origin infrastructure.
+- **Controls:** Configure global and per-client rate limits in the API gateway; enable anomaly detection, bot filtering, and geo/IP reputation lists.
+- **Runbooks & Ownership:** Document escalation paths, communication templates, and decision trees; assign an incident commander and supporting roles.
+- **Testing:** Conduct load and chaos simulations, including failover to secondary CDN providers or scrubbing services; validate alerting thresholds.
+
+## Detection
+- **Monitoring:** Track sudden spikes in requests, connection attempts, or error rates; leverage dashboards for edge/provider metrics and origin health.
+- **Alerting:** Trigger alerts on defined thresholds (e.g., 2× baseline RPS, elevated SYN packets, elevated 5xx). Include context about impacted edge POPs or regions.
+- **Classification:** Determine attack type (volumetric, protocol, application-layer) by examining traffic signatures and comparing against historical patterns.
+
+## Mitigation
+- **Edge Actions:** Activate or tighten WAF/DDoS policies (challenge/deny), enable scrubbing centers, and apply geo/IP blocks or rate limiting. Reference vendor playbooks (AWS Shield Advanced, Cloudflare Magic Transit) for canned responses.
+- **Gateway Controls:** Increase throttling, enforce stricter authentication challenges, or degrade non-essential endpoints/features. Disable high-cost endpoints temporarily.
+- **Origin Hardening:** Scale out stateless services, shed low-priority workloads, and ensure backpressure (circuit breakers, queue length thresholds) is active.
+- **Traffic Steering:** Shift load across regions/providers if available; coordinate with ISPs for null routing or traffic scrubbing when malicious segments persist.
+
+## Communication
+- **Internal:** Keep engineering, SRE, security, support, and leadership informed via incident channel and status updates (timeline, actions, risks).
+- **External:** Update status pages, customer communications, and, if necessary, external partners/ISPs. Provide guidance on expected impact and mitigation progress.
+
+## Recovery & Postmortem
+- **Validation:** Confirm attack subsided, revert temporary policies cautiously, and monitor for secondary waves.
+- **Data Capture:** Preserve logs, traffic captures, and timeline for forensic analysis; document decisions, tooling effectiveness, and gaps.
+- **Follow-Up:** File action items (automation, tooling improvements, provider contracts, playbook refinements) and schedule a blameless postmortem review.
+
+## References & Tooling
+- **Providers:** AWS Shield/CloudFront (Shield Advanced), Azure Front Door with DDoS Protection, Google Cloud Armor, Cloudflare, Akamai Kona.
+- **Detection:** Prometheus/Grafana dashboards, ELK/Loki logging, packet captures, provider analytics.
+- **Testing:** DDoS simulation platforms, load-testing tools (k6, Locust), chaos engineering frameworks.
+
+## Provider Quick Notes
+- **AWS Shield Advanced:** Pre-authorize AWS SRT access, confirm WebACL coverage through AWS WAF, and enable Shield Advanced automatic application layer mitigation on CloudFront. Use AWS Firewall Manager to push emergency rate limits and log Shield metrics to CloudWatch for incident timelines.
+- **Cloudflare:** Toggle "Under Attack" mode, apply bot-fight and zone-level rate limits, and escalate to Cloudflare support with a shield ticket if the attack exceeds self-service policies. Keep Magic Transit or Spectrum tunnels warmed for network-layer absorption and verify Argo Smart Routing remains enabled for legit clients.
+- **Google Cloud Armor:** Use preconfigured WAF rules plus adaptive protection for behavioral anomalies, pin emergency rate-based rules to load balancer backends, and coordinate with the Google Cloud DDoS response team for scrubbing when volumetric traffic persists.
+- **Azure Front Door:** Switch to DDoS Protection Standard, tighten WAF managed rules with anomaly scoring, and engage Azure Rapid Response (via Microsoft support plan) for coordinated mitigation. Mirror changes on Application Gateway if hybrid routing is in play.
+- **Akamai Kona:** Trigger emergency Kona Site Defender policies, leverage adaptive rate controls, and loop in the Akamai SOC for hands-on tuning. Validate origin shield and fail-open/closed preferences match the current incident strategy.
+
+## Diagram Ideas
+- Timeline of detection → mitigation actions → recovery.
+- Layered architecture showing traffic flow through CDN/WAF, load balancer, services, and data stores.
+- Decision tree for choosing mitigation tactics based on attack type (volumetric vs application-layer).
diff --git a/07. System Design/diagrams/api_gateway_flow.md b/07. System Design/diagrams/api_gateway_flow.md
new file mode 100644
index 0000000..fa7ee6b
--- /dev/null
+++ b/07. System Design/diagrams/api_gateway_flow.md	
@@ -0,0 +1,37 @@
+# API Gateway Request Flow
+
+```mermaid
+graph TD
+    classDef edge fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
+    classDef gateway fill:#ede7f6,stroke:#512da8,color:#311b92;
+    classDef service fill:#fff3e0,stroke:#ef6c00,color:#bf360c;
+    classDef data fill:#f1f8e9,stroke:#33691e,color:#1b5e20;
+    classDef observability fill:#fbe9e7,stroke:#d84315,color:#bf360c;
+
+    Client[Client] --> Edge[CDN / WAF]
+    Edge --> Gateway[API Gateway]
+    Gateway -->|Auth validation| AuthProvider[Auth Provider]
+    Gateway -->|Rate limit| QuotaStore[Quota Store]
+    Gateway --> Router{Routing Rules}
+    Router --> ServiceA[Service A]
+    Router --> ServiceB[Service B]
+    Router --> BFF[Mobile BFF Service]
+    BFF --> ServiceC[Service C]
+    ServiceA --> CacheDB[(Cache / Database)]
+    ServiceB --> QueueStore[(Queue / Database)]
+    ServiceC --> ServiceDB[(Database)]
+    Gateway --> Observability[Metrics / Logs / Traces]
+    Observability --> OpsDash[Ops Dashboards]
+
+    class Client,Edge edge;
+    class Gateway,Router gateway;
+    class AuthProvider,BFF,ServiceA,ServiceB,ServiceC service;
+    class QuotaStore,CacheDB,QueueStore,ServiceDB data;
+    class Observability,OpsDash observability;
+```
+
+**Notes**
+- Edge layer shields against DDoS/threats before the gateway.
+- Gateway handles authentication, rate limiting, and routing.
+- Mobile BFF tailors responses for mobile clients.
+- Observability pipeline catches metrics/logs/traces for dashboards.
diff --git a/07. System Design/diagrams/cache_read_write_sequence.md b/07. System Design/diagrams/cache_read_write_sequence.md
new file mode 100644
index 0000000..e4bd190
--- /dev/null
+++ b/07. System Design/diagrams/cache_read_write_sequence.md	
@@ -0,0 +1,33 @@
+# Cache Read/Write Flow (Cache-Aside)
+
+```mermaid
+sequenceDiagram
+    participant C as Client
+    participant G as API Gateway
+    participant S as Service
+    participant K as Cache
+    participant D as Database
+
+    C->>G: 1. HTTP Request (product detail)
+    G->>S: Forward request (auth context)
+    S->>K: Check cache (GET product:123)
+    alt Cache Hit
+        K-->>S: Cached payload
+        S-->>C: Response (from cache)
+    else Cache Miss
+        K-->>S: Miss
+        S->>D: Query product 123
+        D-->>S: Product record
+        S->>K: Populate cache (TTL=300s, idempotent write)
+        note right of K: TTL 5 min, tag=product:123
+        S-->>C: Response (fresh)
+    end
+    opt Invalidations
+        S->>K: Delete on update (event-driven)
+    end
+```
+
+**Key Points**
+- Cache miss triggers database read and cache populate with TTL.
+- Optional invalidation step ensures updates propagate (e.g., on write path/event).
+- Mention TTL and idempotent writes during interviews.
diff --git a/07. System Design/diagrams/data_sharding_map.md b/07. System Design/diagrams/data_sharding_map.md
new file mode 100644
index 0000000..58e7298
--- /dev/null
+++ b/07. System Design/diagrams/data_sharding_map.md	
@@ -0,0 +1,46 @@
+# Data Sharding Topology
+
+```mermaid
+graph TD
+    classDef router fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
+    classDef primary fill:#fff3e0,stroke:#ef6c00,color:#bf360c;
+    classDef replica fill:#f1f8e9,stroke:#33691e,color:#1b5e20;
+    classDef observability fill:#fbe9e7,stroke:#d84315,color:#bf360c;
+    classDef metadata fill:#ede7f6,stroke:#512da8,color:#311b92;
+    classDef upstream fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
+
+    ClientService[Upstream Service] --> Router[Shard Router / Metadata Service]
+    Router -->|Tenant A| ShardAPrimary[Shard A Primary]
+    Router -->|Tenant B| ShardBPrimary[Shard B Primary]
+    Router -->|Tenant C| ShardCPrimary[Shard C Primary]
+
+    ShardAPrimary --> ShardAReplica[Shard A Replica] --- Note["Replication async (latency < 200ms)."]
+    ShardBPrimary --> ShardBReplica[Shard B Replica]
+    ShardCPrimary --> ShardCReplica[Shard C Replica]
+
+    ShardAPrimary --> MonitoringA[Metrics / Logs]
+    ShardBPrimary --> MonitoringB[Metrics / Logs]
+    ShardCPrimary --> MonitoringC[Metrics / Logs]
+
+    Router --> Metadata[(Shard Map / Config)]
+    Metadata --> Router
+
+    subgraph Rebalancing
+        direction TB
+        NewShard[Shard D Primary]
+        Router -. move tenant .-> NewShard
+        ShardAPrimary -. migrate data .-> NewShard
+    end
+
+    class ClientService upstream;
+    class Router router;
+    class ShardAPrimary,ShardBPrimary,ShardCPrimary,NewShard primary;
+    class ShardAReplica,ShardBReplica,ShardCReplica replica;
+    class MonitoringA,MonitoringB,MonitoringC observability;
+    class Metadata metadata;
+```
+
+**Notes**
+- Router consults shard map to send tenants to the correct primary.
+- Each shard has primaries and replicas for HA; monitoring feeds are shown for observability.
+- Rebalancing adds new shard and migrates tenant/data gradually; mention latency impact of async replication.
diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
new file mode 100644
index 0000000..1d37608
--- /dev/null
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -0,0 +1,66 @@
+# Kubernetes Cluster Architecture
+
+```mermaid
+graph TB
+    classDef client fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
+    classDef control fill:#ede7f6,stroke:#512da8,color:#311b92;
+    classDef worker fill:#fff3e0,stroke:#ef6c00,color:#bf360c;
+    classDef network fill:#f1f8e9,stroke:#33691e,color:#1b5e20;
+
+    Clients[kubectl / CI Pipelines] -->|REST| APIServer[API Server]
+
+    subgraph ControlPlane[Control Plane]
+        direction TB
+        APIServer
+        Controller[Controller Manager]
+        Scheduler
+        Etcd[(etcd)]
+    end
+
+    APIServer --> Controller
+    APIServer --> Scheduler
+    APIServer --> Etcd
+
+    subgraph WorkerNodes[Worker Nodes - representative]
+        direction TB
+        Kubelet[Kubelet]
+        KubeProxy[Kube-proxy]
+        PodA[Pod A]
+        PodB[Pod B]
+        PodC[Pod C]
+    end
+
+    Controller --> Kubelet
+    Scheduler --> PodA
+    Scheduler --> PodB
+    Scheduler --> PodC
+
+    Kubelet --> PodA
+    Kubelet --> PodB
+    Kubelet --> PodC
+
+    subgraph Networking[Networking]
+        direction TB
+        Ingress[Ingress Controller]
+        Service[Service - ClusterIP/LoadBalancer]
+        CNI[CNI Plugin]
+    end
+
+    Ingress --> Service
+    Service --> PodA
+    Service --> PodB
+    Service --> PodC
+    CNI <-->|Pod networking| PodA
+    CNI <-->|Pod networking| PodB
+    CNI <-->|Pod networking| PodC
+
+    class Clients client;
+    class APIServer,Controller,Scheduler,Etcd control;
+    class Kubelet,KubeProxy,PodA,PodB,PodC worker;
+    class Ingress,Service,CNI network;
+```
+
+**Notes**
+- Control plane components manage desired state; worker nodes (others implied) run kubelet/kube-proxy and host pods.
+- Ingress/Service expose workloads; CNI handles pod networking.
+- External clients interact via `kubectl`/CI hitting the API server.
diff --git a/07. System Design/diagrams/kubernetes_rolling_update.md b/07. System Design/diagrams/kubernetes_rolling_update.md
new file mode 100644
index 0000000..2b02a05
--- /dev/null
+++ b/07. System Design/diagrams/kubernetes_rolling_update.md	
@@ -0,0 +1,23 @@
+# Kubernetes Rolling Update Timeline
+
+```mermaid
+gantt
+    title Deployment Rolling Update
+    dateFormat  X
+    axisFormat  %s
+
+    section Phase 1
+    Launch surge pod (replicas=5)   :active, 0, 1
+    Readiness check                 :         1, 1
+
+    section Phase 2
+    Route traffic to new pod (stable=4) : 2, 1
+    Terminate old pod                  : 3, 1
+
+    section Phase 3
+    Repeat for remaining pods         : 4, 4
+```
+
+**Notes**
+- `maxSurge=1` and `maxUnavailable=1` keep total replicas between 4 and 5 during rollout.
+- Readiness probes gate traffic; a failed probe pauses or rolls back.
diff --git a/07. System Design/diagrams/load_balancer_blue_green.md b/07. System Design/diagrams/load_balancer_blue_green.md
new file mode 100644
index 0000000..dfe82e7
--- /dev/null
+++ b/07. System Design/diagrams/load_balancer_blue_green.md	
@@ -0,0 +1,18 @@
+# Load Balancer Blue/Green Deployment
+
+```mermaid
+stateDiagram-v2
+    [*] --> Blue
+    Blue --> Canary: Shift traffic to canary (95%/5%)
+    Canary --> Green: Promote to 100%
+    Green --> [*]
+    Canary --> Blue: Rollback (monitoring alerts)
+
+    note right of Blue: Stable environment (95% traffic)
+    note right of Canary: Monitor error rate / latency dashboards
+    note right of Green: New environment receives 100% traffic
+```
+
+**Notes**
+- Show traffic percentages and monitoring checkpoints; rollback returns traffic to blue if canary metrics spike.
+```
diff --git a/07. System Design/diagrams/load_balancer_health.md b/07. System Design/diagrams/load_balancer_health.md
new file mode 100644
index 0000000..0ad261b
--- /dev/null
+++ b/07. System Design/diagrams/load_balancer_health.md	
@@ -0,0 +1,30 @@
+# Load Balancer Health Check Sequence
+
+```mermaid
+sequenceDiagram
+    participant LB as Load Balancer
+    participant Service as Service Instance
+
+    LB->>Service: Probe /healthz (interval 10s)
+    alt Healthy
+        Service-->>LB: 200 OK
+        LB->>LB: Reset failure count
+    else Unhealthy
+        Service-->>LB: Timeout / 5xx
+        LB->>LB: Increment failure count
+        LB->>Service: Retry probe (backoff)
+        alt Threshold reached (3 failures)
+            LB->>LB: Remove from pool
+            LB->>Service: Continue probing (every 30s)
+            Service-->>LB: 200 OK
+            LB->>LB: Re-register instance
+        else Recover before threshold
+            Service-->>LB: 200 OK
+            LB->>LB: Reset failure count
+        end
+    end
+```
+
+**Notes**
+- Combine active probes with passive checks; remove instance after threshold, reinstate once healthy (3 consecutive successes).
+```
diff --git a/07. System Design/diagrams/microservices_context.md b/07. System Design/diagrams/microservices_context.md
new file mode 100644
index 0000000..9296d6c
--- /dev/null
+++ b/07. System Design/diagrams/microservices_context.md	
@@ -0,0 +1,70 @@
+# Microservices Context Map
+
+```mermaid
+graph TB
+    classDef infra fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
+    classDef service fill:#fff3e0,stroke:#ef6c00,color:#bf360c;
+    classDef data fill:#f1f8e9,stroke:#33691e,color:#1b5e20;
+
+    subgraph Shared Infrastructure
+        direction TB
+        Gateway[API Gateway]
+        Discovery[Service Discovery]
+        Observability[Observability Stack]
+    end
+
+    subgraph Catalog Context
+        direction TB
+        CatalogService[Catalog Service]
+        InventoryService[Inventory Service]
+        PricingService[Pricing Service]
+        CatalogDB[(Catalog DB)]
+    end
+
+    subgraph Orders Context
+        direction TB
+        OrderService[Order Service]
+        PaymentService[Payment Service]
+        ShippingService[Shipping Service]
+        OrderDB[(Order DB)]
+    end
+
+    subgraph Users Context
+        direction TB
+        AuthService[Auth Service]
+        ProfileService[Profile Service]
+        UserDB[(User DB)]
+    end
+
+    Gateway --> CatalogService
+    Gateway --> OrderService
+    Gateway --> AuthService
+
+    CatalogService --> Discovery
+    OrderService --> Discovery
+    AuthService --> Discovery
+
+    CatalogService --> Observability
+    OrderService --> Observability
+    AuthService --> Observability
+
+    CatalogService --> CatalogDB
+    InventoryService --> CatalogDB
+    PricingService --> CatalogDB
+
+    OrderService --> OrderDB
+    PaymentService --> OrderDB
+    ShippingService --> OrderDB
+
+    AuthService --> UserDB
+    ProfileService --> UserDB
+
+    class Gateway,Discovery,Observability infra;
+    class CatalogService,InventoryService,PricingService,OrderService,PaymentService,ShippingService,AuthService,ProfileService service;
+    class CatalogDB,OrderDB,UserDB data;
+```
+
+**Notes**
+- Shared infrastructure provides gateway, discovery, and observability for bounded contexts.
+- Each context owns its data store; additional services follow the same pattern (not shown).
+- Highlight ownership boundaries and shared dependencies during interviews.
diff --git a/07. System Design/diagrams/microservices_request_sequence.md b/07. System Design/diagrams/microservices_request_sequence.md
new file mode 100644
index 0000000..429a65d
--- /dev/null
+++ b/07. System Design/diagrams/microservices_request_sequence.md	
@@ -0,0 +1,32 @@
+# Microservices Request Journey
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant Gateway as API Gateway
+    participant BFF as Mobile BFF Service
+    participant ServiceA as Service A
+    participant ServiceB as Service B
+    participant EventBus as Event Bus
+    participant Inventory as Inventory Service
+    participant Metrics as Observability
+
+    Client->>Gateway: HTTPS Request (Place order)
+    Gateway->>BFF: Forward request with auth context
+    BFF->>ServiceA: Validate request & orchestrate
+    ServiceA->>Metrics: Emit trace span
+    ServiceA->>Inventory: Check stock
+    Inventory-->>ServiceA: Stock status
+    ServiceA->>ServiceB: Charge payment (REST)
+    ServiceB-->>ServiceA: Payment result
+    ServiceA->>EventBus: Publish OrderCreated event
+    EventBus->>Inventory: Async reserve stock
+    EventBus->>Metrics: Emit event metrics
+    ServiceA-->>BFF: Order response
+    BFF-->>Client: Success (order id)
+    Note over ServiceA,EventBus: Compensation path on failure (refund/release stock)
+```
+
+**Notes**
+- Sequence mixes synchronous calls with async events; highlight tracing spans and metrics.
+- Mention saga/compensation logic if payment or inventory fails.
diff --git a/07. System Design/diagrams/system_architecture_map.md b/07. System Design/diagrams/system_architecture_map.md
new file mode 100644
index 0000000..c4a040c
--- /dev/null
+++ b/07. System Design/diagrams/system_architecture_map.md	
@@ -0,0 +1,87 @@
+# System Design Architecture Map
+
+```mermaid
+graph TB
+    classDef client fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
+    classDef edge fill:#bbdefb,stroke:#1565c0,color:#0d47a1;
+    classDef ingress fill:#ede7f6,stroke:#512da8,color:#311b92;
+    classDef sync fill:#fff3e0,stroke:#ef6c00,color:#bf360c;
+    classDef async fill:#ffe0b2,stroke:#ef6c00,color:#bf360c;
+    classDef data fill:#f1f8e9,stroke:#33691e,color:#1b5e20;
+    classDef observability fill:#fbe9e7,stroke:#d84315,color:#bf360c;
+
+    subgraph Clients
+        A[Web Client]
+        B[Mobile Client]
+        C[Partner Integration]
+    end
+    subgraph Edge
+        D[DNS]
+        E[CDN / WAF]
+    end
+    subgraph Ingress
+        F[Load Balancer]
+        G[API Gateway]
+    end
+    subgraph Services
+        H[Service A]
+        I[Service B]
+        J[Service C]
+    end
+    subgraph Data
+        K[(Cache)]
+        L[(Database)]
+        M[(Queue)]
+    end
+    subgraph Observability
+        N[Metrics]
+        O[Logs]
+        P[Traces]
+    end
+    Q[Ops Dashboards]
+
+    A --> D
+    B --> D
+    C --> D
+    D --> E
+    E --> F
+    F --> G
+    G --> H
+    G --> I
+    G --> J
+
+    H --> K
+    I --> K
+    H --> L
+    I --> L
+    J --> M
+    M --> I
+
+    H --> N
+    H --> O
+    H --> P
+    I --> N
+    I --> O
+    I --> P
+    J --> N
+    J --> O
+    J --> P
+
+    N --> Q
+    O --> Q
+    P --> Q
+
+    class H,I sync;
+    class J async;
+    class K,L,M data;
+    class A,B,C client;
+    class D,E edge;
+    class F,G ingress;
+    class N,O,P,Q observability;
+```
+
+**Legend**
+- Sync Service: Service A / Service B
+- Async Service: Service C (Queue)
+- Data Stores: Cache, Database, Queue
+- Observability: Metrics, Logs, Traces feeding Ops dashboards
diff --git a/07. System Design/kubernetes.md b/07. System Design/kubernetes.md
new file mode 100644
index 0000000..8a8869d
--- /dev/null
+++ b/07. System Design/kubernetes.md	
@@ -0,0 +1,54 @@
+# Kubernetes Operations Deep Dive
+
+Refresh the essentials for deploying, scaling, and troubleshooting workloads on Kubernetes.
+
+## Cheat Sheet
+- **Core assets:** Pods, deployments, services, configmaps/secrets, ingress, statefulsets.
+- **Control loop mindset:** Declarative desired state via API server, reconciled by controllers (deployments, HPA, kube-scheduler).
+- **Interview hook:** Discuss an incident or migration involving Kubernetes rollout or cluster tuning.
+
+## Quick Refresh
+- **Cluster Architecture:** API server, etcd, controller manager, scheduler on control plane; kubelet, kube-proxy, CNI on worker nodes.
+- **Workload Types:** Deployments for stateless apps, StatefulSets for ordered pods, DaemonSets for node agents, Jobs/CronJobs for batch; align choices with service boundaries discussed in [Microservices Architecture](microservices.md).
+- **Networking:** ClusterIP, NodePort, LoadBalancer services; ingress controllers; CNI plugins (Calico, Cilium). Understand service discovery via DNS.
+- **Config & Secrets:** Inject environment variables or volumes; manage rotation; leverage external secret stores when needed.
+- **Scaling:** Horizontal Pod Autoscaler (metrics-based), Vertical Pod Autoscaler, Cluster Autoscaler. Know resource requests/limits and bin packing considerations.
+- **Reliability:** Readiness/liveness/startup probes, rolling updates, PodDisruptionBudgets, PodTopologySpread.
+- **Security:** RBAC, namespaces, network policies, PodSecurity (admission controllers), image scanning, runtime policies.
+- **Observability:** Use kubectl, kubectl top, metrics-server, Prometheus/Grafana, logging stacks (ELK, Loki), tracing sidecars.
+
+## Patterns & Trade-Offs
+- **Multi-tenant Clusters:** Namespaces and resource quotas provide isolation; consider separate clusters for strict isolation or compliance.
+- **Blue/Green & Canary Releases:** Leverage multiple deployments, service selectors, or progressive delivery tools (Argo Rollouts, Flagger).
+- **Service Mesh Integration:** Envoy/Linkerd sidecars for mTLS, retries, traffic shaping; weigh added complexity.
+- **Stateful Workloads:** Use StatefulSets with persistent volumes (CSI drivers). Consider operator patterns for databases.
+- **Hybrid/Edge Deployments:** Manage clusters across cloud and on-prem with fleet managers (Anthos, EKS Anywhere, AKS Arc).
+
+## Example Anecdotes
+- **Cluster outage:** Misconfigured resource limits starved system pods; implementing resource requests and monitoring prevented recurrence.
+- **Deploy rollback:** Failed rollout recovered via Deployment revision history and `kubectl rollout undo`.
+- **Autoscaling surprise:** HPA oscillations due to bursty metrics; added custom metrics and stabilization windows.
+- **Security audit:** RBAC gaps uncovered cross-namespace access; tightened roles, added network policies, and enabled OPA Gatekeeper.
+
+## Interview Prompts
+- How do you debug a pod stuck in CrashLoopBackOff? What commands do you run first?
+- Explain how you would design CI/CD to deploy safely to Kubernetes across environments.
+- Describe how you secure inter-service traffic and sensitive configuration inside a cluster.
+- What indicators tell you it’s time to split clusters or adopt a platform team?
+
+## Deep Dive Later
+- Operators (Kubebuilder, Operator SDK) for custom lifecycle automation.
+- GitOps workflows with Argo CD or Flux.
+- Cluster autoscaling tunables and cost-optimization strategies.
+- Chaos engineering on Kubernetes (LitmusChaos, PowerfulSeal).
+
+## Diagram Ideas
+- Control plane vs worker node architecture diagram.
+- Deployment rollout timeline showing replicas, readiness probes, and service selector updates.
+- Network flow: ingress → service → pod, highlighting CNI path and policies.
+
+### Diagram Prep Notes
+1. Architecture: list control plane components (API server, etcd, controller-manager, scheduler) and worker pieces (kubelet, kube-proxy, CNI plugin).
+2. Rolling update: capture initial replica count, surge/unavailable settings, readiness probes gating traffic.
+
+Drafts: cluster overview (`diagrams/kubernetes_cluster.md`) and rolling update timeline (`diagrams/kubernetes_rolling_update.md`).
diff --git a/07. System Design/load_balancer.md b/07. System Design/load_balancer.md
new file mode 100644
index 0000000..1c9b093
--- /dev/null
+++ b/07. System Design/load_balancer.md	
@@ -0,0 +1,65 @@
+# Load Balancer Deep Dive
+
+Use this guide to explain load balancers quickly, cover common follow-up questions, and show awareness of real-world trade-offs.
+
+## Cheat Sheet
+- **Why it matters:** Evenly distribute traffic, tolerate instance failures, and provide a single entry point for clients.
+- **Key knobs:** Layer 4 (TCP/UDP) vs Layer 7 (HTTP), health checks, stickiness, connection draining, traffic splitting.
+- **Trade-offs:** Simplicity vs flexibility, latency overhead, stateful features vs stateless scaling.
+- **Interview hook:** Describe one incident or migration where LB configuration saved or harmed reliability.
+
+## Quick Refresh
+- **Core function:** Accept client connections, select a healthy backend, and proxy the request/response.
+- **Edge integration:** Assume upstream CDN/WAF handles DDoS scrubbing before traffic reaches the load balancer; ensure health checks and rate limits align across layers.
+- **Algorithms:** Round-robin, least connections, weighted, IP hash, random with two choices. Know when each applies.
+- **Health Monitoring:** TCP pings vs HTTP health endpoints; consider warmup time, circuit breaking, auto-removal.
+- **Session Affinity:** Cookie-based or IP-based stickiness to support stateful backends; discuss downsides (hot spots, failover).
+- **TLS Termination:** Offload cert management to the load balancer or re-encrypt to backend for end-to-end security.
+- **Blue/Green & Canary:** Use weighted routing or header-based rules to shift traffic safely.
+
+## Patterns & Trade-Offs
+
+### Layer 4 vs Layer 7
+- **Layer 4:** Faster, protocol-agnostic (TCP/UDP), minimal inspection. Ideal for raw throughput and non-HTTP protocols.
+- **Layer 7:** Understands HTTP headers, paths, cookies. Enables routing by URL, A/B testing, auth integration.
+- **Trade-off:** L7 adds latency and complexity but unlocks smarter routing and observability.
+
+### Active vs Passive Health Checks
+- **Active:** Periodic probes detect failures proactively; risk false positives if backend warmup is slow.
+- **Passive:** Observe real traffic responses to mark backends unhealthy; slower to react but lower overhead.
+- **Combine both** to balance sensitivity and stability.
+
+### Horizontal vs Vertical Scaling
+- **Horizontal:** Multiple load balancer instances behind DNS or anycast; remove single point of failure.
+- **Vertical:** Beefier single appliance—simpler but risky. Prefer managed services (AWS ALB/NLB, GCP LB, nginx/HAProxy clusters).
+
+### Global Traffic Management
+- **DNS-based:** Geo or latency routing at the DNS layer; slower failover (TTL dependent).
+- **Anycast:** Same IP advertised from multiple regions; requires resilient routing and consistent configs.
+- **Hybrid:** DNS directs to regional LBs, which handle local distribution.
+
+## Example Anecdotes
+- **Canary gone wrong:** Weighted routing misconfigured, sending 50% traffic to a canary that needed 5%. Lesson: start with tiny percents and monitor closely.
+- **Sticky sessions and outages:** Application relied on in-memory sessions; LB failover sent users to cold nodes, causing login loops. Solution: shared session store or stateless design.
+- **TLS certificate expiration:** Centralized termination meant one missed renewal impacted entire service. Mitigation: automate renewals, add monitoring, or use managed certs.
+- **Auto-scaling mismatch:** Load balancer health checks marked instances healthy before warmup, routing traffic too early. Fix: custom health endpoints that verify dependencies and caches.
+
+## Interview Prompts
+- Explain how you’d add a new service behind an existing load balancer (DNS updates, health checks, rollout).
+- Contrast using a managed cloud LB vs running nginx/HAProxy yourself.
+- Describe how you diagnose uneven load distribution across backends.
+- Discuss how load balancing changes in a multi-region or hybrid-cloud design.
+
+## Deep Dive Later
+- Review vendor docs: AWS ALB/NLB, Google Cloud LB, Azure Front Door.
+- Experiment with HAProxy or Envoy configs locally; practice weighted routing and health checks.
+- Study SRE postmortems involving load balancing misconfigurations to gather storytelling ammo.
+
+## Diagram Ideas
+- Sequence diagram: client → DNS → load balancer → healthy backend with health-check feedback loop.
+- Architecture sketch: cross-zone load balancers feeding auto-scaled instances, highlighting blue/green weights.
+- Failure timeline: unhealthy node detection, removal, and reintegration after health checks pass.
+
+### Diagram Prep Notes
+1. Health check sequence: annotate intervals (e.g., every 10s), failure threshold, and recovery workflow.
+2. Blue/green architecture: depict traffic splitter with percentage labels and monitoring dashboards tracking error rates.
diff --git a/07. System Design/microservices.md b/07. System Design/microservices.md
new file mode 100644
index 0000000..bb83156
--- /dev/null
+++ b/07. System Design/microservices.md	
@@ -0,0 +1,66 @@
+# Microservices Architecture Deep Dive
+
+Understand how to decompose, deploy, and operate services that collaborate without collapsing under complexity.
+
+## Cheat Sheet
+- **Why microservices?** Independent deployment, focused ownership, and heterogeneous stacks for fast iteration.
+- **When to avoid?** Small teams, simple domains, or when DevOps maturity and observability tooling are lacking.
+- **Core building blocks:** Service boundaries, contracts (APIs/events), discovery, observability, resilience patterns.
+- **Interview hook:** Share a migration success or pain point from monolith to microservices.
+
+## Quick Refresh
+- **Service Boundaries:** Slice by business capability or bounded contexts. Minimize shared databases. Define contract-first APIs and versioning strategy.
+- **Communication Patterns:** Synchronous REST/gRPC for request/response; asynchronous messaging/streaming for decoupling and backpressure.
+- **Service Discovery:** Use registry (Consul, etcd, Eureka) or platform (Kubernetes DNS, service mesh). Highlight health checks and circuit breakers; revisit deployment primitives in [Kubernetes Operations](kubernetes.md).
+- **Data Ownership:** Each service owns its datastore. Handle cross-service queries via composition, CQRS, or data replication.
+- **Observability:** Standardize logging, metrics, tracing (OpenTelemetry). Implement correlation IDs across calls.
+- **Resilience:** Employ retries with jitter, circuit breakers, bulkheads, load shedding, and graceful degradation.
+- **Governance:** Maintain API guidelines, shared libraries, security policies, and guardrails for proliferation.
+
+## Patterns & Trade-Offs
+
+### Monolith to Microservices Migration
+- **Strangler Fig:** Incrementally peel features into services behind routing rules.
+- **Modular Monolith First:** Enforce module boundaries before splitting processes.
+- **Parallel Change:** Dual-write or mirror traffic to new services for validation.
+
+### Communication Styles
+- **REST/gRPC:** Simplicity, widespread tooling, but risk of chatty I/O.
+- **Messaging/Event-driven:** Loose coupling and eventual consistency; added complexity in ordering, replay, and idempotency.
+- **GraphQL/BFF:** Tailored responses per client; introduces federation/aggregation services.
+
+### Operational Footprint
+- **DevOps Requirements:** Automated CI/CD, infrastructure-as-code, standardized observability.
+- **Platform Support:** Kubernetes, ECS, Nomad, or PaaS for deployment orchestration (see [Kubernetes Operations](kubernetes.md)).
+- **Security:** Zero-trust posture with mTLS, JWT, policy-as-code (OPA), secret management.
+
+## Example Anecdotes
+- **Release velocity:** Post-migration, teams shipped weekly vs quarterly but required investment in CI/CD and feature flagging.
+- **Incident response:** A cascading failure caused by synchronous dependencies; implementing circuit breakers and async queues reduced blast radius.
+- **Data consistency:** Event-driven replication introduced lag; eventually added read models and compensation workflows.
+- **Ownership clarity:** Microservices exposed unclear domain boundaries; adopting DDD workshops realigned service scopes.
+
+## Interview Prompts
+- When would you choose microservices over a monolith, and what prerequisites must be in place?
+- How do you manage data consistency across services that own different data stores?
+- Describe strategies for breaking a legacy monolith into microservices without halting feature delivery.
+- How do you debug a user request spanning multiple services?
+
+## Deep Dive Later
+- Domain-driven design (DDD) for boundary identification.
+- Service meshes (Istio, Linkerd) for traffic management and policy enforcement.
+- Event sourcing, CQRS, and saga patterns for distributed transactions.
+- Team topology patterns (Conway’s Law) and platform engineering approaches.
+
+Need a refresher on edge defenses and request flow? Pair this guide with the [System Design Refresher](system_design_refresher.md).
+
+## Diagram Ideas
+- Context map showing bounded contexts and service interactions.
+- Sequence diagram of user request traversing gateway, multiple services, and data stores.
+- Deployment topology: services on Kubernetes/ECS with discovery, mesh, and observability sidecars.
+
+### Diagram Prep Notes
+1. Context map: note bounded contexts (e.g., Orders, Payments, Catalog) and shared components (gateway, discovery, observability stack).
+2. Request journey: map synchronous calls vs async events; label tracing spans to show propagation.
+
+Drafts: context map (`diagrams/microservices_context.md`) and request journey (`diagrams/microservices_request_sequence.md`).
diff --git a/07. System Design/overview.md b/07. System Design/overview.md
new file mode 100644
index 0000000..a8a218f
--- /dev/null
+++ b/07. System Design/overview.md	
@@ -0,0 +1,7 @@
+# System Design Overview
+
+**Architecture Flow:** Balance latency, availability, and cost by sketching client → edge (CDN/WAF/DDoS) → load balancer → services → data paths; see the [System Design Refresher](system_design_refresher.md) for structured walkthroughs.
+
+**Component Deep Dives:** Revisit routing, auth, and scaling nuances via the [Load Balancer](load_balancer.md), [API Gateway](api_gateway.md), [Caching Strategies](caching_strategies.md), and [Data Sharding & Storage Tiering](data_sharding.md) guides.
+
+**Terminology Radar:** Keep the [System Design Glossary](system_design_glossary.md) open for availability models, consistency terminology, queueing concepts, and operational vocabulary.
diff --git a/07. System Design/system_design_glossary.md b/07. System Design/system_design_glossary.md
new file mode 100644
index 0000000..2043fc2
--- /dev/null
+++ b/07. System Design/system_design_glossary.md	
@@ -0,0 +1,54 @@
+# System Design Glossary
+
+Keep these core terms at your fingertips when discussing distributed systems, reliability, and scaling trade-offs.
+
+## Availability & Reliability
+- **Availability:** Percentage of time a system is operational. Expressed in “nines” (e.g., 99.9% ⇒ ~8h45m downtime/year).
+- **Reliability:** Probability a system performs correctly under stated conditions for a period. Often tied to mean time between failures (MTBF).
+- **SLA / SLO / SLI:** Agreement, objective, and indicator describing expected performance and how it is measured.
+- **Failover:** Automatic switching to a standby system upon failure (active-active vs active-passive).
+- **Graceful Degradation:** System continues providing limited functionality under stress.
+
+## Consistency Models
+- **Strong Consistency:** Reads return the most recent write (linearizability). Often requires coordination and higher latency.
+- **Eventual Consistency:** Data converges without guaranteeing immediate synchronization. Suitable for high availability.
+- **Read-after-write Consistency:** A writer immediately sees its own write; others may observe delayed updates.
+- **Consistency Spectrum:** CAP theorem (Consistency, Availability, Partition tolerance) and PACELC (If Partition, choose Availability or Consistency; Else, trade Latency vs Consistency).
+- **Consensus Protocols:** Paxos, Raft, Zab—used to achieve agreement among distributed nodes.
+
+## Latency & Throughput
+- **Latency:** Time to complete a single request. Tail latency (p95/p99) reveals worst-case behavior.
+- **Throughput:** Number of requests processed per unit time. Balanced via concurrency and resource utilization.
+- **Backpressure:** Mechanism to slow producers when consumers are overwhelmed (e.g., queue limits, credit-based flow control).
+- **Circuit Breaker:** Component that trips after failures to prevent cascading impact, allowing fallback or retries after cooldown.
+
+## Queueing & Messaging
+- **Message Queue:** Decouples producer and consumer via FIFO or topic-based delivery (e.g., RabbitMQ, SQS).
+- **Stream Processing:** Append-only logs (Kafka, Kinesis) enabling ordered consumption and replay.
+- **At-least-once vs Exactly-once:** Delivery guarantees; at-least-once requires idempotency, exactly-once is harder, often achieved via transactional semantics.
+- **Dead Letter Queue (DLQ):** Holds messages that repeatedly fail processing for later inspection.
+
+## Scaling & Partitioning
+- **Horizontal Scaling:** Add more nodes (stateless services, sharded databases).
+- **Vertical Scaling:** Increase resources of a single node (CPU, RAM); limited headroom.
+- **Partitioning / Sharding:** Splitting data or workload across nodes based on key or range.
+- **Rebalancing:** Moving load/data between partitions to maintain even distribution.
+
+## Observability & Operations
+- **Metrics:** Numeric time-series (request rate, error rate, latency).
+- **Logs:** Structured/unstructured event records for debugging.
+- **Tracing:** Follows a request through distributed services, capturing spans and timing.
+- **Runbooks:** Step-by-step operational guides for incidents or routine tasks.
+
+## Security & Networking
+- **mTLS (Mutual TLS):** Both client and server present certificates for authentication.
+- **Rate Limiting:** Control request rate via token bucket, leaky bucket, or fixed window.
+- **Zero Trust:** Never trust, always verify; apply auth/authz at every boundary.
+- **Web Application Firewall (WAF):** Filters HTTP(S) traffic to block exploits (e.g., SQL injection, XSS) and often sits with CDN/DDoS layers before the load balancer.
+- **Service Mesh:** Infrastructure layer (e.g., Istio, Linkerd) providing traffic management, observability, and security for microservices.
+
+## Cost & Efficiency
+- **Load Shedding:** Intentionally dropping low-priority work during overload to protect core functionality.
+- **Autoscaling:** Adjusting resources automatically based on metrics (CPU, QPS, custom).
+- **Capacity Planning:** Forecasting resource needs; includes headroom policies and growth modeling.
+- **Resource Utilization:** Measuring how efficiently CPU, memory, IO, and networking are used.
diff --git a/07. System Design/system_design_refresher.md b/07. System Design/system_design_refresher.md
new file mode 100644
index 0000000..be66565
--- /dev/null
+++ b/07. System Design/system_design_refresher.md	
@@ -0,0 +1,77 @@
+# System Design Refresher
+
+Use this guide to frame architecture discussions quickly, explain trade-offs, and see how edge defense, load balancing, services, and data layers compose before diving into component-specific guides.
+
+## Cheat Sheet
+- Start with the north star: product goals, scale assumptions (traffic, data, latency, availability).
+- Draw the high-level flow first (client → edge → application → data) before zooming into components.
+- Discuss trade-offs using standard lenses: latency vs consistency, throughput vs cost, build vs buy.
+- Name failure modes and mitigation strategies (replication, retries, backpressure, circuit breakers).
+
+## Quick Refresh
+- **Requirements:** Collect functional (features, reads vs writes) and non-functional (SLAs, compliance) constraints. Call out unknowns and suggest safe assumptions.
+- **High-Level Architecture:** Describe entry points (CDN, DNS, API gateway), application layer (services, queues), and persistence (databases, caches, object stores).
+- **Data Design:** Choose storage models (SQL, NoSQL, search) based on access patterns. Mention partitioning, replication, and schema evolution.
+- **Scaling Patterns:** Explain horizontal vs vertical scaling, stateless services, autoscaling, and multi-region replication. Know when to leverage managed services.
+- **Resiliency:** Cover health checks, load balancing, failover, backoff/retry policies, circuit breakers, and observability (metrics, traces, logs).
+- **Security & Edge Defense:** Touch on auth/authz, secrets management, encryption, rate limiting, WAF/CDN-based DDoS protection, and API gateway concerns.
+
+### Architecture Map Outline (for upcoming diagram)
+1. Clients (web, mobile, partners) connect through DNS to CDN/WAF/DDoS shield.
+2. Edge forwards sanitized traffic to regional load balancers with health-checked service pools.
+3. API gateway enforces auth/rate-limits and routes to stateless microservices.
+4. Services interact with caches, queues/streams, and data stores (SQL/NoSQL/object storage).
+5. Observability pipeline (metrics, logs, traces) and admin interfaces feed back into operations.
+
+## Core Components
+
+### Load Balancer
+- Routes traffic across healthy backend instances; supports layer 4 (TCP) or layer 7 (HTTP) balancing.
+- Implements health checks, stickiness, and traffic splitting for blue/green or canary deployments.
+- Failure modes: unhealthy instance churn, uneven load distribution, single-region outages. Mitigations include cross-zone balancing and auto-scaling integrations.
+
+### Edge Protection (CDN / WAF / DDoS Shield)
+- CDN/WAF sits in front of load balancers to absorb volumetric attacks, cache static assets, and enforce threat rules.
+- Integrates with DDoS scrubbing centers and rate limiting to drop malicious traffic before it hits the application tier.
+- Coordinate logging and alerting to escalate when attack thresholds are exceeded; rehearse failover to alternate providers.
+
+#### DDoS Mitigation Checklist
+- Traffic inspection: enable WAF rules, bot detection, and anomaly scoring at the edge provider.
+- Rate controls: configure global and per-client rate limits; propagate limits through API gateway policies.
+- Scrubbing & failover: contract managed DDoS scrubbing service or multi-CDN strategy with automated failover.
+- Network hardening: restrict direct access to load balancer IPs via ACLs/security groups; expose only via edge layer.
+- Runbooks & drills: maintain step-by-step response plans and rehearse load tests/attack simulations with stakeholders.
+
+Reference the shared [DDoS Response Playbook](ddos_playbook.md) for a full preparation, detection, mitigation, and recovery workflow.
+
+For service decomposition and deployment platform specifics, pair this refresher with the [Microservices Architecture guide](microservices.md) and the [Kubernetes Operations guide](kubernetes.md).
+
+### API Gateway
+- Central entry point for client requests; handles routing, authentication, rate limiting, and request transformation.
+- Enables versioning, monetization, and observability across microservices.
+- Thin vs rich gateways: decide how much business logic to embed to avoid new bottlenecks.
+
+### Caching Layer
+- Reduce latency and offload primary stores with CDN edge caches, application caches (Redis/Memcached), and database caches.
+- Define TTL, eviction policies, and cache invalidation strategies (write-through, write-behind, cache-aside).
+- Plan for consistency: eventual consistency may be acceptable; invalidate on writes or changes in upstream data.
+
+### Data Storage & Sharding
+- Select storage engines to match workload (transactional, analytical, blob, search).
+- Partition data via range, hash, or geo sharding; manage hot partitions and rebalancing.
+- Combine replication (for availability) with sharding (for scale) and describe monitoring for lag or split-brain scenarios.
+
+## Practice Drills
+- Pick a familiar product (news feed, ride sharing, e-commerce checkout) and sketch the architecture in three layers: ingress, services, data.
+- Time-box 15-minute designs: 5 minutes requirements, 5 minutes architecture, 5 minutes deep dive on a component or trade-off.
+- Practice “what if” pivots: sudden traffic spikes, data deletion requests, region outages, third-party dependency failures.
+
+## Deep Dive Later
+- Explore managed offerings (AWS ALB, API Gateway, CloudFront, DynamoDB, RDS, GCP equivalents) and their limitations.
+- Study real-world postmortems to sharpen failure analysis stories.
+- Maintain glossaries for consistency models (strong, eventual, causal) and messaging patterns (queues vs streams).
+
+## Diagram Ideas
+- High-level architecture: clients → CDN/WAF → load balancer → services → databases/queues/cache.
+- Sequence diagram for read/write paths highlighting consistency and caching touchpoints.
+- Failure game plan: visualizing circuit breaker, retry, and fallback interactions during an outage.
diff --git a/README.md b/README.md
index 051c36d..e8dac17 100644
--- a/README.md
+++ b/README.md
@@ -1,34 +1,69 @@
-Interview Questions & Answers
-=========
+# Interview Questions & Answers
 
+A focused refresher for software engineers who need to get back to interview shape fast, with deep-dive sections for longer study sessions.
 
-When you prepare to **interview with a company** you need to remember *(or learn)* specific questions from your area.
-I have added most interesting questions from my own interviews with well known companies.
+## Quick Ramp-Up (10–15 minutes)
+- Skim `General Prep` items to re-activate interview mindset and communication patterns.
+- Revisit one technical section that matches your next interview (e.g. Web, Python, Databases) and jot down gaps.
+- Consult your dedicated Algorithms & Data Structures repository for a fast coding warm-up; keep this repo focused on broader interview readiness.
 
-Topics
----------
+## Table of Contents
 
-Here you find some topicts that help you prepare to interview:
-- [General interview questions](chapters/general_questions.md)
-- [Web development](chapters/web_development.md)
-- [Python](chapters/python.md) and [Django](chapters/django.md)
-- [Java](chapters/java.md)
-- [JavaScript](chapters/javascript.md)
-- [Databases](chapters/databases.md) including MySQL, PostgreSQL and MongoDB
-- [Algorithmic questions](chapters/algorithms.md) is a general part for all interviews on developer position
-- [Git](chapters/git.md)
+### 01. General Prep
+- [Overview](01.%20General%20Prep/overview.md)
+- [General interview questions](01.%20General%20Prep/general_questions.md)
+- [Authentication vs Authorization](01.%20General%20Prep/authentication_vs_authorization.md)
+- [Git](01.%20General%20Prep/git.md)
 
-Data Structures & Algorithms
----------
+### 02. Web Development
+- [Overview](02.%20Web%20Development/overview.md)
+- [Web development](02.%20Web%20Development/web_development.md)
+- [JavaScript](02.%20Web%20Development/javascript.md)
 
-All links below are follow to the external websites.
+### 03. Backend & Frameworks
+- [Overview](03.%20Backend%20%26%20Frameworks/overview.md)
+- [Python](03.%20Backend%20%26%20Frameworks/python.md)
+- [Django](03.%20Backend%20%26%20Frameworks/django.md)
+- [Java](03.%20Backend%20%26%20Frameworks/java.md)
 
-- [Disjoint-set data structure](https://en.wikipedia.org/wiki/Disjoint-set_data_structure). Used to join few sets those have partial overlapping.
+### 04. Data & Storage
+- [Overview](04.%20Data%20%26%20Storage/overview.md)
+- [Databases](04.%20Data%20%26%20Storage/databases.md)
 
-Books & Articles
----------
+### 05. Interview Strategy
+- [Overview](05.%20Interview%20Strategy/overview.md)
+- [Algorithmic questions](05.%20Interview%20Strategy/algorithms.md) — high-level framing; defer detailed practice to the dedicated Algorithms & Data Structures repo.
 
-Also you can read some good books that can help increase your chances to be hired:
-- [Cracking the Coding Interview, 6th Edition](https://google.com/search?q=Cracking+the+Coding+Interview,+6th+Edition) that tells you not only about technical skills, but also how to prepare yourself before interview
-- [Introduction to Algorithms. Thomas Cormen](https://google.com/search?q=Cormen+Algorithms)
-- [Algorithms and Data Structures](https://github.com/1st/algorithms/) mini-book
+### 06. Behavioral Interviews
+- [Overview](06.%20Behavioral%20Interviews/overview.md)
+- [Behavioral Interview Playbook](06.%20Behavioral%20Interviews/behavioral_playbook.md)
+- [Behavioral Interview Question Bank](06.%20Behavioral%20Interviews/behavioral_questions.md)
+
+### 07. System Design
+Start with the refresher for the end-to-end flow (edge DDoS shield → load balancer → services → data), then dive into specific components below.
+- [Overview](07.%20System%20Design/overview.md)
+- [System Design Refresher](07.%20System%20Design/system_design_refresher.md)
+- [Load Balancer Deep Dive](07.%20System%20Design/load_balancer.md)
+- [API Gateway Deep Dive](07.%20System%20Design/api_gateway.md)
+- [Caching Strategies](07.%20System%20Design/caching_strategies.md)
+- [Data Sharding & Storage Tiering](07.%20System%20Design/data_sharding.md)
+- [System Design Glossary](07.%20System%20Design/system_design_glossary.md)
+- [DDoS Response Playbook](07.%20System%20Design/ddos_playbook.md)
+- [Microservices Architecture](07.%20System%20Design/microservices.md)
+- [Kubernetes Operations](07.%20System%20Design/kubernetes.md)
+
+## How to Use This Repository
+- Start with **Quick Ramp-Up** when you only have a few minutes.
+- Dive into the linked sections for refreshed explanations, example answers, and external references.
+- Add personal notes in each section to capture stories, metrics, or differentiators for your interviews.
+- Keep deep algorithm drills in the separate Algorithms & Data Structures repository to avoid overlap.
+
+## External References
+
+### Data Structures & Algorithms
+- [Disjoint-set data structure](https://en.wikipedia.org/wiki/Disjoint-set_data_structure) — efficient for joining overlapping sets.
+
+### Books & Articles
+- [Cracking the Coding Interview, 6th Edition](https://google.com/search?q=Cracking+the+Coding+Interview,+6th+Edition) — covers technical prep and soft skills.
+- [Introduction to Algorithms. Thomas Cormen](https://google.com/search?q=Cormen+Algorithms) — foundational algorithms reference.
+- [Algorithms and Data Structures](https://github.com/1st/algorithms/) — concise GitHub mini-book.
diff --git a/chapters/algorithms.md b/chapters/algorithms.md
deleted file mode 100644
index 9a4a65a..0000000
--- a/chapters/algorithms.md
+++ /dev/null
@@ -1,105 +0,0 @@
-Interview Questions with Algorithmic tasks
-=========
-
-
-This chapter will help you to get answers on typical interview questions for **all type of developers**.
-This is **Algorithmic questions** that you will hear on your next interview.
-Be prepared for this type of questions in advance, because it's not easy questions and you need to understand it, not only read answers.
-
-**I've created a [mini book about algorithms](https://github.com/1st/algorithms/) to help you be prepared to the algorithmic questions.**
-
-
-Questions list
----------
-
-#### How to calculate function complexity?
-
-Read [Complexity function](http://en.wikipedia.org/wiki/Complexity_function) and [Big O notation](http://en.wikipedia.org/wiki/Big_O_notation).
-
-
-#### Create `sqrt` function
-
-```python
-code here
-```
-
-#### Find substring positon
-
-```python
-# general language-independent implementation
-def find_substr(string, substr):
-    """Check if string contains substring.
-
-    >>> find_substr('', '')
-    True
-    >>> find_substr('', 'a')
-    False
-    >>> find_substr('a', '')
-    True
-    >>> find_substr('a', 'a')
-    True
-    >>> find_substr('a', 'aa')
-    False
-    >>> find_substr('aa', 'a')
-    True
-    >>> find_substr('abc', 'abc')
-    True
-    >>> find_substr('abcd', 'abc')
-    True
-    >>> find_substr('ababc', 'abc')
-    True
-    >>> find_substr('ababcd', 'abc')
-    True
-    >>> find_substr('abcabc', 'abcd')
-    False
-    """
-    for i in range(0, len(string) - len(substr) + 1):
-        for j in range(0, len(substr)):
-            if substr[j] != string[i + j]:
-                break
-        else:
-            return True
-    return False
-```
-
-```python
-# pythonic implementation with string slice
-def find_substr(string, substr):
-    return any(substr == string[i:i + len(substr)] for i in range(len(string) - len(substr) + 1))
-```
-
-#### Create function that return all string permutations
-
-Given string and we need to return all permutations of this string.
-
-
-```python
-def permute_string(original_string):
-    """
-    >>> permute_string('')
-    []
-    >>> permute_string('a')
-    ['a']
-    >>> permute_string('ab')
-    ['ab', 'ba']
-    >>> permute_string('abc')
-    ['abc', 'bac', 'bca', 'acb', 'cab', 'cba']
-    """
-    results = []
-    
-    if len(original_string) == 0:
-        return results
-
-    ch = original_string[0]
-    substrings = permute_string(original_string[1:])
-
-    if not substrings:
-        results.append(ch)
-
-    for substring in substrings:
-        for index in range(len(substring) + 1):
-            tmp_str = substring[0:index] + ch + substring[index:]
-            results.append(tmp_str)
-        
-    return results
-```
diff --git a/chapters/databases.md b/chapters/databases.md
deleted file mode 100644
index 0f97815..0000000
--- a/chapters/databases.md
+++ /dev/null
@@ -1,28 +0,0 @@
-Interview Questions. Databases
-=========
-
-
-This chapter will help you to get answers on typical interview questions for **developers who use databases** in work.
-
-
-Questions list
----------
-
-#### What difference between `MyISAM` and `InnoDB`?
-
-`MyISAM` allow to create full-text search index, but doesn't have support of transactions and foreign keys.
-
-`InnoDB` supports transations and foreign keys.
-
-
-#### How to use `compotite key`?
-
-**Composite key** is used if we need to create index based on two or more columns. If we need to search by first column from composite key - we don't need to create additional index. But for all other columns that follow after this first column - we need to create additonal indexes.
-
-For example, we have table `users` with 3 columns: `name`, `age` and `company_name`. We have composite key for all 3 columns `KEY (name, age, company_name)`. In this case we can search user by `name` OR by `name` and `age` OR by `name`, `age` and `company_name`. But we can't search by `age` or `company_name` because index should find `name` before go forward to search by next column. To search by `age` or `company_name` we need to create an additonal index.
-
-
-Good to know
----------
-
- * [Partial index](https://en.wikipedia.org/wiki/Partial_index)
diff --git a/chapters/django.md b/chapters/django.md
deleted file mode 100644
index ebc10b4..0000000
--- a/chapters/django.md
+++ /dev/null
@@ -1,13 +0,0 @@
-Interview Questions for Django
-=========
-
-
-This chapter will help you to get answers on typical interview questions for **Django** role.
-
-Also you need to prepare yourself for [Python interview questions](python.md) as well.
-
-
-Questions list
----------
-
- * [What's the difference between select_related and prefetch_related in Django ORM?](https://stackoverflow.com/a/31237071/718722)
diff --git a/chapters/general_questions.md b/chapters/general_questions.md
deleted file mode 100644
index 8817d20..0000000
--- a/chapters/general_questions.md
+++ /dev/null
@@ -1,11 +0,0 @@
-Interview Questions in general
-=========
-
-
-This chapter will help you to get answers on typical interview questions for **all type of developers**.
-
-
-Questions list
----------
-
-- [100 Potential Interview Questions](http://career-advice.monster.com/job-interview/interview-questions/100-potential-interview-questions/article.aspx)
diff --git a/chapters/git.md b/chapters/git.md
deleted file mode 100644
index e0cac2a..0000000
--- a/chapters/git.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Git
-
-### Q: How to list branches in Git?
-
-```sh
-# Show list of local branches and highlight a current working branch
-git branch
-# Show all branches in local and remote repositories
-git branch -a
-# Show only remote branches
-git branch -r
-```
-
-### Q: How to find merged/unmerged branches in git?
-
-```sh
-# all merged
-git branch --merged master
-# all not merged yet
-git branch --no-merged master
-# or all local and remote
-git branch -r --no-merged origin/master
-```
-Source: [StackOverflow](https://stackoverflow.com/a/12276041/718722)
-
-### Q: How to remove local (untracked) files from the current Git working tree?
-
-```sh
-# Print out the list of files which will be removed (dry run)
-git clean -n
-# Delete the files from the repository
-git clean -f
-# Remove untracked files, including directories (-d) and files ignored by git (-x)
-git clean -d -x -f
-```
-Source: [StackOverflow](https://stackoverflow.com/a/64966/718722)
-
-Alternative solution:
-```sh
-# Discard uncommitted changes in a specific file
-git checkout thefiletoreset.txt
-# To reset the entire repository to the last committed state
-git reset --hard
-```
-Source: [StackOverflow](https://stackoverflow.com/a/675797/718722)
-
-### Q: Merging vs. Rebasing
-
-Source: [Atlassian](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
-
-## Other topics
-
-- [Advanced Git Tutorials](https://www.atlassian.com/git/tutorials/advanced-overview) by Atlassian
diff --git a/chapters/java.md b/chapters/java.md
deleted file mode 100644
index 9aab508..0000000
--- a/chapters/java.md
+++ /dev/null
@@ -1,11 +0,0 @@
-Interview Questions for Java developer
-=========
-
-
-This chapter will help you to get answers on typical interview questions for **Java developer** role.
-
-
-Questions on interview
----------
-
-- [Why do we use autoboxing and unboxing in Java?](http://stackoverflow.com/questions/27647407/why-do-we-use-autoboxing-and-unboxing-in-java)
diff --git a/chapters/javascript.md b/chapters/javascript.md
deleted file mode 100644
index 9c7806e..0000000
--- a/chapters/javascript.md
+++ /dev/null
@@ -1,20 +0,0 @@
-Interview Questions for JavaScript web developer
-=========
-
-
-This chapter will help you to get answers on typical interview questions for **JavaScript web developer** role.
-
-
-Questions list
----------
-
-#### How to prevent form send?
-
-See question **event.preventDefault() vs. return false** on [stackoverflow](http://stackoverflow.com/questions/1357118/)
-
-
-Good to know
----------
-
- * [16 Great JavaScript Interview Questions](http://www.toptal.com/javascript/interview-questions)
- * [JavaScript "Use Strict"](http://www.w3schools.com/js/js_strict.asp)
diff --git a/chapters/python.md b/chapters/python.md
deleted file mode 100644
index aa92107..0000000
--- a/chapters/python.md
+++ /dev/null
@@ -1,141 +0,0 @@
-Interview Questions for Python developer
-=========
-
-
-This chapter will help you to get answers on typical interview questions for **Python developer** role.
-
-Also you may be interested in [Django interview questions](django.md) as well.
-
-
-Read this first
----------
-
-- What is [Iterators](https://wiki.python.org/moin/Iterator) and [Generators](https://wiki.python.org/moin/Generators)
-
-
-Questions list
----------
-
-
-#### What is `GIL`
-
-`GIL` *(Global Interpreter Lock)* is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython's memory management is not thread-safe.
-
-Read: [Global Interpreter Lock](https://wiki.python.org/moin/GlobalInterpreterLock)
-
-#### What types of data is used in python?
-
-Python provides some built-in data types: `dict`, `list`, `set`, `frozenset` and `tuple`.
-
-In **Python 2.x** we have `str` class that used to hold *binary data and 8-bit text*, and the `unicode` class to handle *Unicode text*.
-
-In **Python 3.x** we have `str` class that used to hold *Unicode strings*, and the `bytes` class is used to hold *binary data*.
-
-Read: [Python Data Types](https://docs.python.org/3/library/datatypes.html)
-
-#### What is `mutable` and `immutable` types?
-
-`Immutable` *(can't be changed in place, only replaced to new value)*: numbers, strings and tuples.
-
-`Mutable`: dictionaries and lists.
-
-#### What difference between `tuple` and `list`
-
-**Tuple** is immutable data type, and **list** is mutable *(see notes below)*.
-
-Example of tuple: `t = (1, 'a', True)` and list: `l = [1, 'a', True]`
-
-#### What is `set`?
-
-`sets` is unordered collections of unique elements. In other words - `set` is a hast table that stored similar to keys in `dict` data type.
-
-Read:
-- [sets](https://docs.python.org/2/library/sets.html) basic info *(deprecated in python 2.6)*
-- [set](https://docs.python.org/2.7/library/stdtypes.html#set) type
-
-
-#### Floats VS Decimals
-
-Given a code that produces "strange" result:
-```python
->>> 0.1 + 0.1 + 0.1 - 0.3
-5.551115123125783e-17
-```
-Please fix it to produce a "correct" result `0.0`.
-
-**Hint:** read about [Decimals](https://docs.python.org/3/library/decimal.html) in Python.
-
-
-Coding examples
----------
-
-#### What happens if you modify default value of named argument in function?
-
-```python
->>> def f(val, l=[]):
->>>     l.append(val)
->>>     print l
->>>
->>> f(10)
-[10]
->>> f(20)
-[10, 20]
->>> # is it unexpected behavior? :-)
-
->>> # now try with dict
->>> def f(val, d={}):
->>>     d[val] = val
->>>     print d
->>>
->>> f(10)
-{10: 10}
->>> f(20)
-{10: 10, 20: 20}
->>> # it's also unexpected behavior!
-```
-
-As we can see - if you try to modify default value of mutable variable - this variable will change own default value. So, be careful! *It's potential place for bugs!*
-
-#### Write test for function
-
-The easiest way to test function - is to use [doctest](https://docs.python.org/2/library/doctest.html) that built-in in Python.
-
-```python
-def my_range(x, y):
-    """
-    This function return range from X to Y.
-    
-    >>> my_range(3, 3)
-    []
-    >>> my_range(0, 1)
-    [0]
-    >>> my_range(0, 3)
-    [0, 1, 2]
-    >>> my_range(1, 7)
-    [1, 2, 3, 4, 5, 6]
-    """
-    return list(range(x, y))
-
-# run our tests
-if __name__ == "__main__":
-    import doctest
-    doctest.testmod()
-```
-
-#### How to show source code of given function?
-
-We can show source code of function with `inspect` package.
-
-```python
->>> import inspect
->>> from django.core.context_processors import request
->>> print inspect.getsource(request)
-def request(request):
-    return {'request': request}
-```
-
-
-Good to know
----------
-
- - [Porting Python 2 Code to Python 3](https://docs.python.org/3/howto/pyporting.html) - helps you to prepare your Python 2.x code to port on Python 3.x
diff --git a/chapters/web_development.md b/chapters/web_development.md
deleted file mode 100644
index 43c9540..0000000
--- a/chapters/web_development.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Interview Questions for Web developer
-
-
-This chapter will help you to get answers on typical interview questions for **Web developers**.
-
-
-## Questions
-
-
-### What are HTTP and TCP
-
-- Read [Hypertext Transfer Protocol](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) on wikipedia
-- Read [Transmission Control Protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
-
-
-### What is `XSS`?
-
-[XSS (Cross-site scripting)](http://en.wikipedia.org/wiki/Cross-site_scripting) is a type of computer security vulnerability. `XSS` enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy.
-
-**Example #1:** user send form with search query with `<script>` tag in it, and this page shows entered by user query without escaping it. In result we have injected JavaScript from external website. Attacher can share link to search results via email or own website.
-
-**Example 2:** attacher can enter `<script>` tag in some field of personal profile on social network website. Whe user visiting page with attacker profile - JavaScript executes and can collect your personal information and send it to attacher email or website.
-
-**Example 3 (DOM-based XSS):** when user visit website with SPA (single-page application) the JavaScript can render content without escaping data that comes from user input - and it can result in the same problem as described above.
-
-
-### How's the web works?
-
-* [How the web works](http://www.garshol.priv.no/download/text/http-tut.html)
-* [How the domain name system works](http://wiki.bravenet.com/How_the_domain_name_system_works)
-
-
-### What is gRPC?
-
-**gRPC** is a high-performance, open-source RPC _(Remote Procedure Call)_ framework developed by Google. It allows services to communicate efficiently across networks using HTTP/2 and supports multiple programming languages.
-
-It uses Protocol Buffers (ProtoBuf) as its default data serialization format, which is more compact and efficient than XML or JSON. gRPC enables features like bidirectional streaming, authentication, load balancing, and automatic code generation from .proto files.