From 3368764e43fc1773d2375062034c949bd0c2c861 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 13:51:54 +0200
Subject: [PATCH 01/37] Changing the file structure

---
 .../authentication_vs_authorization.md        |  22 +++
 01. General Prep/general_questions.md         |  13 ++
 01. General Prep/git.md                       |  57 +++++++
 02. Web Development/javascript.md             |  18 +++
 02. Web Development/web_development.md        |  23 +++
 03. Backend & Frameworks/django.md            |  16 ++
 03. Backend & Frameworks/java.md              |  18 +++
 03. Backend & Frameworks/python.md            |  78 ++++++++++
 04. Data & Storage/databases.md               |  17 +++
 05. Interview Strategy/algorithms.md          |  35 +++++
 README.md                                     |  62 ++++----
 chapters/algorithms.md                        | 105 -------------
 chapters/databases.md                         |  28 ----
 chapters/django.md                            |  13 --
 chapters/general_questions.md                 |  11 --
 chapters/git.md                               |  53 -------
 chapters/java.md                              |  11 --
 chapters/javascript.md                        |  20 ---
 chapters/python.md                            | 141 ------------------
 chapters/web_development.md                   |  37 -----
 20 files changed, 334 insertions(+), 444 deletions(-)
 create mode 100644 01. General Prep/authentication_vs_authorization.md
 create mode 100644 01. General Prep/general_questions.md
 create mode 100644 01. General Prep/git.md
 create mode 100644 02. Web Development/javascript.md
 create mode 100644 02. Web Development/web_development.md
 create mode 100644 03. Backend & Frameworks/django.md
 create mode 100644 03. Backend & Frameworks/java.md
 create mode 100644 03. Backend & Frameworks/python.md
 create mode 100644 04. Data & Storage/databases.md
 create mode 100644 05. Interview Strategy/algorithms.md
 delete mode 100644 chapters/algorithms.md
 delete mode 100644 chapters/databases.md
 delete mode 100644 chapters/django.md
 delete mode 100644 chapters/general_questions.md
 delete mode 100644 chapters/git.md
 delete mode 100644 chapters/java.md
 delete mode 100644 chapters/javascript.md
 delete mode 100644 chapters/python.md
 delete mode 100644 chapters/web_development.md

diff --git a/01. General Prep/authentication_vs_authorization.md b/01. General Prep/authentication_vs_authorization.md
new file mode 100644
index 0000000..e3a76f5
--- /dev/null
+++ b/01. General Prep/authentication_vs_authorization.md	
@@ -0,0 +1,22 @@
+# 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.
+
+## 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.
+
+## 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..83d4b64
--- /dev/null
+++ b/01. General Prep/general_questions.md	
@@ -0,0 +1,13 @@
+# General Interview Questions
+
+Use these prompts to warm up your interview mindset and practice concise storytelling across behavioral and cross-functional topics.
+
+## 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..1ddba5c
--- /dev/null
+++ b/01. General Prep/git.md	
@@ -0,0 +1,57 @@
+# Git Interview Refresh
+
+Keep these branches, cleanup commands, and conceptual contrasts top of mind so you can speak confidently about Git workflows in interviews.
+
+## 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/02. Web Development/javascript.md b/02. Web Development/javascript.md
new file mode 100644
index 0000000..1345ea9
--- /dev/null
+++ b/02. Web Development/javascript.md	
@@ -0,0 +1,18 @@
+# JavaScript Interview Refresh
+
+Focus on browser fundamentals, event handling, and language quirks to keep your JavaScript interviews sharp.
+
+## 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/web_development.md b/02. Web Development/web_development.md
new file mode 100644
index 0000000..0509836
--- /dev/null
+++ b/02. Web Development/web_development.md	
@@ -0,0 +1,23 @@
+# 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.
+
+## 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..2562c66
--- /dev/null
+++ b/03. Backend & Frameworks/django.md	
@@ -0,0 +1,16 @@
+# 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.
+
+## 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..668a1b3
--- /dev/null
+++ b/03. Backend & Frameworks/java.md	
@@ -0,0 +1,18 @@
+# Java Interview Refresh
+
+Revisit JVM fundamentals and language features that frequently appear in Java interview conversations.
+
+## 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/python.md b/03. Backend & Frameworks/python.md
new file mode 100644
index 0000000..22d9fd2
--- /dev/null
+++ b/03. Backend & Frameworks/python.md	
@@ -0,0 +1,78 @@
+# 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.
+
+## 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..9e9a937
--- /dev/null
+++ b/04. Data & Storage/databases.md	
@@ -0,0 +1,17 @@
+# Database Interview Refresh
+
+Reinforce relational storage fundamentals so you can articulate trade-offs, indexing strategies, and engine capabilities in interviews.
+
+## 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.
+
+## 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/05. Interview Strategy/algorithms.md b/05. Interview Strategy/algorithms.md
new file mode 100644
index 0000000..58dc98c
--- /dev/null
+++ b/05. Interview Strategy/algorithms.md	
@@ -0,0 +1,35 @@
+# 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/).
+
+## Quick Refresh
+- Recall how to describe time and space complexity using Big O, and rehearse concise definitions for `O(1)`, `O(n log n)`, and `O(n^2)`.
+- Be ready to narrate your problem-solving process: clarify requirements, outline approach, validate with examples, and discuss trade-offs.
+- Keep a short list of go-to data structures (arrays, hash maps, stacks/queues, trees/graphs) and what problems they fit.
+
+## 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.
+
+## Deep Dive Later
+- 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/README.md b/README.md
index 051c36d..cffaab5 100644
--- a/README.md
+++ b/README.md
@@ -1,34 +1,46 @@
-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
+- [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
+- [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
+- [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
+- [Databases](04.%20Data%20%26%20Storage/databases.md)
 
-Books & Articles
----------
+### 05. Interview Strategy
+- [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
+## 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.

From c63309998768496287cfc3ce14370be0022f401a Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 14:46:03 +0200
Subject: [PATCH 02/37] Extend information in each section

---
 .../authentication_vs_authorization.md           | 16 ++++++++++++++++
 01. General Prep/general_questions.md            |  5 +++++
 01. General Prep/git.md                          |  5 +++++
 02. Web Development/javascript.md                |  5 +++++
 02. Web Development/web_development.md           |  5 +++++
 03. Backend & Frameworks/django.md               |  5 +++++
 03. Backend & Frameworks/java.md                 |  5 +++++
 03. Backend & Frameworks/python.md               |  5 +++++
 04. Data & Storage/databases.md                  |  5 +++++
 05. Interview Strategy/algorithms.md             |  5 +++++
 10 files changed, 61 insertions(+)

diff --git a/01. General Prep/authentication_vs_authorization.md b/01. General Prep/authentication_vs_authorization.md
index e3a76f5..37c712f 100644
--- a/01. General Prep/authentication_vs_authorization.md	
+++ b/01. General Prep/authentication_vs_authorization.md	
@@ -5,10 +5,26 @@ Authentication and authorization work together to guard access, but they solve d
 - **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.
diff --git a/01. General Prep/general_questions.md b/01. General Prep/general_questions.md
index 83d4b64..383a83c 100644
--- a/01. General Prep/general_questions.md	
+++ b/01. General Prep/general_questions.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/01. General Prep/git.md b/01. General Prep/git.md
index 1ddba5c..bfd2a55 100644
--- a/01. General Prep/git.md	
+++ b/01. General Prep/git.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/02. Web Development/javascript.md b/02. Web Development/javascript.md
index 1345ea9..aef8205 100644
--- a/02. Web Development/javascript.md	
+++ b/02. Web Development/javascript.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/02. Web Development/web_development.md b/02. Web Development/web_development.md
index 0509836..1bb946d 100644
--- a/02. Web Development/web_development.md	
+++ b/02. Web Development/web_development.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/03. Backend & Frameworks/django.md b/03. Backend & Frameworks/django.md
index 2562c66..29fbe17 100644
--- a/03. Backend & Frameworks/django.md	
+++ b/03. Backend & Frameworks/django.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/03. Backend & Frameworks/java.md b/03. Backend & Frameworks/java.md
index 668a1b3..050e187 100644
--- a/03. Backend & Frameworks/java.md	
+++ b/03. Backend & Frameworks/java.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/03. Backend & Frameworks/python.md b/03. Backend & Frameworks/python.md
index 22d9fd2..9f1632d 100644
--- a/03. Backend & Frameworks/python.md	
+++ b/03. Backend & Frameworks/python.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/04. Data & Storage/databases.md b/04. Data & Storage/databases.md
index 9e9a937..136ca75 100644
--- a/04. Data & Storage/databases.md	
+++ b/04. Data & Storage/databases.md	
@@ -2,6 +2,11 @@
 
 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.
diff --git a/05. Interview Strategy/algorithms.md b/05. Interview Strategy/algorithms.md
index 58dc98c..187eb76 100644
--- a/05. Interview Strategy/algorithms.md	
+++ b/05. Interview Strategy/algorithms.md	
@@ -2,6 +2,11 @@
 
 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/).
 
+## 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.
+
 ## Quick Refresh
 - Recall how to describe time and space complexity using Big O, and rehearse concise definitions for `O(1)`, `O(n log n)`, and `O(n^2)`.
 - Be ready to narrate your problem-solving process: clarify requirements, outline approach, validate with examples, and discuss trade-offs.

From d6b14d1ec414bc022beab5ed8c903c4bdc10495f Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 16:05:27 +0200
Subject: [PATCH 03/37] Add Overview for each section

---
 01. General Prep/overview.md         | 7 +++++++
 02. Web Development/overview.md      | 5 +++++
 03. Backend & Frameworks/overview.md | 7 +++++++
 04. Data & Storage/overview.md       | 5 +++++
 05. Interview Strategy/overview.md   | 7 +++++++
 README.md                            | 7 +++++++
 6 files changed, 38 insertions(+)
 create mode 100644 01. General Prep/overview.md
 create mode 100644 02. Web Development/overview.md
 create mode 100644 03. Backend & Frameworks/overview.md
 create mode 100644 04. Data & Storage/overview.md
 create mode 100644 05. Interview Strategy/overview.md

diff --git a/01. General Prep/overview.md b/01. General Prep/overview.md
new file mode 100644
index 0000000..df95a37
--- /dev/null
+++ b/01. General Prep/overview.md	
@@ -0,0 +1,7 @@
+# General Prep Overview
+
+Lead with a crisp elevator pitch (role → impact → why now) and keep three STAR stories handy for conflict, failure, and big wins; detailed prompts sit in [General interview questions](general_questions.md).
+
+Remember that authentication proves identity (passwords, MFA, SSO) while authorization enforces least-privilege access once identity is known — sketch the login → token → permission check flow before diving into [Authentication vs Authorization](authentication_vs_authorization.md).
+
+Round things out by reviewing Git essentials: list and prune branches, explain merge vs rebase trade-offs, and practice safe cleanup with `git clean -n` before `-f`, using [Git Interview Refresh](git.md) for command specifics.
diff --git a/02. Web Development/overview.md b/02. Web Development/overview.md
new file mode 100644
index 0000000..2454e31
--- /dev/null
+++ b/02. Web Development/overview.md	
@@ -0,0 +1,5 @@
+# Web Development Overview
+
+Trace an HTTP request from DNS lookup through TLS, caches/CDNs, app servers, and persistence so you can articulate latency and scaling levers — see [Web Development Interview Refresh](web_development.md) for the full walkthrough.
+
+Keep JavaScript top of mind by explaining the event loop, microtasks vs macrotasks, and the difference between `preventDefault()` and `return false`, while remembering `"use strict"` quirks; drill further with [JavaScript Interview Refresh](javascript.md).
diff --git a/03. Backend & Frameworks/overview.md b/03. Backend & Frameworks/overview.md
new file mode 100644
index 0000000..af63fa9
--- /dev/null
+++ b/03. Backend & Frameworks/overview.md	
@@ -0,0 +1,7 @@
+# Backend & Frameworks Overview
+
+Revisit Python by describing how the GIL shapes concurrency, contrasting mutable vs immutable types, and prepping quick doctest-style examples — extended notes live in [Python Interview Refresh](python.md).
+
+For Django, remind yourself how `select_related` and `prefetch_related` tame query counts, how auth can be customized, and what caching or async add-ons support scaling, as captured in [Django Interview Refresh](django.md).
+
+Round out with Java: compare primitives to wrappers (autoboxing costs), outline JVM memory and GC tuning levers, and highlight concurrency utilities such as `CompletableFuture`, with more detail in [Java Interview Refresh](java.md).
diff --git a/04. Data & Storage/overview.md b/04. Data & Storage/overview.md
new file mode 100644
index 0000000..5b2739e
--- /dev/null
+++ b/04. Data & Storage/overview.md	
@@ -0,0 +1,5 @@
+# Data & Storage Overview
+
+Choose relational engines based on ACID guarantees, indexing features, and workload fit (OLTP vs analytics).
+
+Apply leftmost-prefix rules when designing composite indexes, and lean on `EXPLAIN` plus slow-query logs to tune performance — all captured in the [Database Interview Refresh](databases.md).
diff --git a/05. Interview Strategy/overview.md b/05. Interview Strategy/overview.md
new file mode 100644
index 0000000..0dc046f
--- /dev/null
+++ b/05. Interview Strategy/overview.md	
@@ -0,0 +1,7 @@
+# Interview Strategy Overview
+
+Lead algorithm discussions by stating target complexities, narrating the clarify → plan → code → test loop, and mapping problems to go-to data structures; the talking points live in [Interview Questions with Algorithmic Tasks](algorithms.md).
+
+A behavioral playbook (coming soon) will bundle STAR templates and question prompts so stories stay sharp without revisiting every chapter.
+
+A system design refresher (coming soon) will capture caching, load balancing, API gateways, storage, and consistency patterns to prime whiteboard sessions.
diff --git a/README.md b/README.md
index cffaab5..4202dbe 100644
--- a/README.md
+++ b/README.md
@@ -10,24 +10,31 @@ A focused refresher for software engineers who need to get back to interview sha
 ## Table of Contents
 
 ### 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)
 
 ### 02. Web Development
+- [Overview](02.%20Web%20Development/overview.md)
 - [Web development](02.%20Web%20Development/web_development.md)
 - [JavaScript](02.%20Web%20Development/javascript.md)
 
 ### 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)
 
 ### 04. Data & Storage
+- [Overview](04.%20Data%20%26%20Storage/overview.md)
 - [Databases](04.%20Data%20%26%20Storage/databases.md)
 
 ### 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.
+- Behavioral Interview Playbook _(coming soon)_
+- System Design Refresher _(coming soon — caching, load balancing, API gateways, resiliency patterns)_
 
 ## How to Use This Repository
 - Start with **Quick Ramp-Up** when you only have a few minutes.

From 5346c7b6831d6a63c576e6818ec553472891c53a Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 22:37:22 +0200
Subject: [PATCH 04/37] Move Behavioral Interviews and System Design to new
 sections

---
 05. Interview Strategy/overview.md            |  4 +-
 .../behavioral_playbook.md                    | 48 ++++++++++++++++++
 .../behavioral_questions.md                   | 38 ++++++++++++++
 06. Behavioral Interviews/overview.md         |  7 +++
 07. System Design/overview.md                 |  7 +++
 07. System Design/system_design_refresher.md  | 49 +++++++++++++++++++
 README.md                                     | 15 +++++-
 7 files changed, 163 insertions(+), 5 deletions(-)
 create mode 100644 06. Behavioral Interviews/behavioral_playbook.md
 create mode 100644 06. Behavioral Interviews/behavioral_questions.md
 create mode 100644 06. Behavioral Interviews/overview.md
 create mode 100644 07. System Design/overview.md
 create mode 100644 07. System Design/system_design_refresher.md

diff --git a/05. Interview Strategy/overview.md b/05. Interview Strategy/overview.md
index 0dc046f..502d482 100644
--- a/05. Interview Strategy/overview.md	
+++ b/05. Interview Strategy/overview.md	
@@ -2,6 +2,4 @@
 
 Lead algorithm discussions by stating target complexities, narrating the clarify → plan → code → test loop, and mapping problems to go-to data structures; the talking points live in [Interview Questions with Algorithmic Tasks](algorithms.md).
 
-A behavioral playbook (coming soon) will bundle STAR templates and question prompts so stories stay sharp without revisiting every chapter.
-
-A system design refresher (coming soon) will capture caching, load balancing, API gateways, storage, and consistency patterns to prime whiteboard sessions.
+Use the dedicated Behavioral Interviews section for STAR storytelling materials, and the System Design section for architectural patterns once those guides are published.
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..248b538
--- /dev/null
+++ b/06. Behavioral Interviews/overview.md	
@@ -0,0 +1,7 @@
+# Behavioral Interviews Overview
+
+Anchor every conversation in structured storytelling, measurable impact, and self-awareness.
+
+Practice your go-to STAR narratives for leadership, conflict, failure, and cross-functional wins in the [Behavioral Interview Playbook](behavioral_playbook.md).
+
+Build a question bank to ask interviewers about team culture, delivery cadence, and success metrics using the [Behavioral Interview Question Bank](behavioral_questions.md).
diff --git a/07. System Design/overview.md b/07. System Design/overview.md
new file mode 100644
index 0000000..7e55494
--- /dev/null
+++ b/07. System Design/overview.md	
@@ -0,0 +1,7 @@
+# System Design Overview
+
+Explain how you balance latency, availability, and cost by applying foundational patterns.
+
+Outline request flow diagrams and component responsibilities with the [System Design Refresher](system_design_refresher.md) covering caching, load balancing, API gateways, and data layers.
+
+Collect deep dives on specific components — `load_balancer.md`, `api_gateway.md`, `caching_strategies.md`, and `data_sharding.md` (coming soon) — to keep examples fresh.
diff --git a/07. System Design/system_design_refresher.md b/07. System Design/system_design_refresher.md
new file mode 100644
index 0000000..42c4a5d
--- /dev/null
+++ b/07. System Design/system_design_refresher.md	
@@ -0,0 +1,49 @@
+# System Design Refresher
+
+Use this guide to frame architecture discussions quickly, explain trade-offs, and dive deeper into specific components when needed.
+
+## 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:** Touch on auth/authz, secrets management, encryption, rate limiting, and API gateway concerns.
+
+## 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.
+
+### 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).
diff --git a/README.md b/README.md
index 4202dbe..c5cc3c4 100644
--- a/README.md
+++ b/README.md
@@ -33,8 +33,19 @@ A focused refresher for software engineers who need to get back to interview sha
 ### 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.
-- Behavioral Interview Playbook _(coming soon)_
-- System Design Refresher _(coming soon — caching, load balancing, API gateways, resiliency patterns)_
+
+### 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
+- [Overview](07.%20System%20Design/overview.md)
+- [System Design Refresher](07.%20System%20Design/system_design_refresher.md)
+- Load Balancer Deep Dive _(coming soon)_
+- API Gateway Deep Dive _(coming soon)_
+- Caching Strategies _(coming soon)_
+- Data Sharding & Storage Tiering _(coming soon)_
 
 ## How to Use This Repository
 - Start with **Quick Ramp-Up** when you only have a few minutes.

From 1b8906545baab8590af83ef8bc5c023e4ca99ba1 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 22:47:50 +0200
Subject: [PATCH 05/37] Add LB and API Gateway

---
 04. Data & Storage/databases.md    | 13 +++++++
 07. System Design/api_gateway.md   | 56 ++++++++++++++++++++++++++++++
 07. System Design/load_balancer.md | 55 +++++++++++++++++++++++++++++
 07. System Design/overview.md      |  2 +-
 README.md                          |  4 +--
 5 files changed, 127 insertions(+), 3 deletions(-)
 create mode 100644 07. System Design/api_gateway.md
 create mode 100644 07. System Design/load_balancer.md

diff --git a/04. Data & Storage/databases.md b/04. Data & Storage/databases.md
index 136ca75..55c9a7d 100644
--- a/04. Data & Storage/databases.md	
+++ b/04. Data & Storage/databases.md	
@@ -12,6 +12,19 @@ Reinforce relational storage fundamentals so you can articulate trade-offs, inde
 - 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.
diff --git a/07. System Design/api_gateway.md b/07. System Design/api_gateway.md
new file mode 100644
index 0000000..a893684
--- /dev/null
+++ b/07. System Design/api_gateway.md	
@@ -0,0 +1,56 @@
+# 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).
+
+## 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.
diff --git a/07. System Design/load_balancer.md b/07. System Design/load_balancer.md
new file mode 100644
index 0000000..10413fa
--- /dev/null
+++ b/07. System Design/load_balancer.md	
@@ -0,0 +1,55 @@
+# 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.
+- **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.
diff --git a/07. System Design/overview.md b/07. System Design/overview.md
index 7e55494..a292a66 100644
--- a/07. System Design/overview.md	
+++ b/07. System Design/overview.md	
@@ -4,4 +4,4 @@ Explain how you balance latency, availability, and cost by applying foundational
 
 Outline request flow diagrams and component responsibilities with the [System Design Refresher](system_design_refresher.md) covering caching, load balancing, API gateways, and data layers.
 
-Collect deep dives on specific components — `load_balancer.md`, `api_gateway.md`, `caching_strategies.md`, and `data_sharding.md` (coming soon) — to keep examples fresh.
+Collect deep dives on specific components — learn the nuances in the [Load Balancer Deep Dive](load_balancer.md) and [API Gateway Deep Dive](api_gateway.md); round out caching and data sharding with upcoming guides.
diff --git a/README.md b/README.md
index c5cc3c4..40da1f2 100644
--- a/README.md
+++ b/README.md
@@ -42,8 +42,8 @@ A focused refresher for software engineers who need to get back to interview sha
 ### 07. System Design
 - [Overview](07.%20System%20Design/overview.md)
 - [System Design Refresher](07.%20System%20Design/system_design_refresher.md)
-- Load Balancer Deep Dive _(coming soon)_
-- API Gateway Deep Dive _(coming soon)_
+- [Load Balancer Deep Dive](07.%20System%20Design/load_balancer.md)
+- [API Gateway Deep Dive](07.%20System%20Design/api_gateway.md)
 - Caching Strategies _(coming soon)_
 - Data Sharding & Storage Tiering _(coming soon)_
 

From 81d91ccce328018d16f719c63afc4029b61d9f97 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 22:50:32 +0200
Subject: [PATCH 06/37] Added Caching Strategies

---
 07. System Design/caching_strategies.md | 66 +++++++++++++++++++++++++
 07. System Design/overview.md           |  2 +-
 README.md                               |  2 +-
 3 files changed, 68 insertions(+), 2 deletions(-)
 create mode 100644 07. System Design/caching_strategies.md

diff --git a/07. System Design/caching_strategies.md b/07. System Design/caching_strategies.md
new file mode 100644
index 0000000..76ba620
--- /dev/null
+++ b/07. System Design/caching_strategies.md	
@@ -0,0 +1,66 @@
+# 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.
diff --git a/07. System Design/overview.md b/07. System Design/overview.md
index a292a66..be8b263 100644
--- a/07. System Design/overview.md	
+++ b/07. System Design/overview.md	
@@ -4,4 +4,4 @@ Explain how you balance latency, availability, and cost by applying foundational
 
 Outline request flow diagrams and component responsibilities with the [System Design Refresher](system_design_refresher.md) covering caching, load balancing, API gateways, and data layers.
 
-Collect deep dives on specific components — learn the nuances in the [Load Balancer Deep Dive](load_balancer.md) and [API Gateway Deep Dive](api_gateway.md); round out caching and data sharding with upcoming guides.
+Collect deep dives on specific components — learn the nuances in the [Load Balancer Deep Dive](load_balancer.md), [API Gateway Deep Dive](api_gateway.md), and [Caching Strategies](caching_strategies.md); round out data sharding with the forthcoming guide.
diff --git a/README.md b/README.md
index 40da1f2..e827a3a 100644
--- a/README.md
+++ b/README.md
@@ -44,7 +44,7 @@ A focused refresher for software engineers who need to get back to interview sha
 - [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 _(coming soon)_
+- [Caching Strategies](07.%20System%20Design/caching_strategies.md)
 - Data Sharding & Storage Tiering _(coming soon)_
 
 ## How to Use This Repository

From b770c9ed67f5252b68ecf53df9f4b30f685a36da Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 22:52:29 +0200
Subject: [PATCH 07/37] Added Data Sharding & Storage Tiering Deep Dive

---
 07. System Design/data_sharding.md | 77 ++++++++++++++++++++++++++++++
 README.md                          |  2 +-
 2 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 07. System Design/data_sharding.md

diff --git a/07. System Design/data_sharding.md b/07. System Design/data_sharding.md
new file mode 100644
index 0000000..69e812f
--- /dev/null
+++ b/07. System Design/data_sharding.md	
@@ -0,0 +1,77 @@
+# 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.
diff --git a/README.md b/README.md
index e827a3a..91f0e38 100644
--- a/README.md
+++ b/README.md
@@ -45,7 +45,7 @@ A focused refresher for software engineers who need to get back to interview sha
 - [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 _(coming soon)_
+- [Data Sharding & Storage Tiering](07.%20System%20Design/data_sharding.md)
 
 ## How to Use This Repository
 - Start with **Quick Ramp-Up** when you only have a few minutes.

From 0fbb15d37ea278dfa61642dfcfc9c795ec0f6b0d Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 22:57:12 +0200
Subject: [PATCH 08/37] Added Interview Framing Tips

---
 05. Interview Strategy/algorithms.md | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/05. Interview Strategy/algorithms.md b/05. Interview Strategy/algorithms.md
index 187eb76..d461610 100644
--- a/05. Interview Strategy/algorithms.md	
+++ b/05. Interview Strategy/algorithms.md	
@@ -6,6 +6,7 @@ Use this chapter as a conversation prep guide for the algorithm portion of inter
 - 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.
 
 ## Quick Refresh
 - Recall how to describe time and space complexity using Big O, and rehearse concise definitions for `O(1)`, `O(n log n)`, and `O(n^2)`.
@@ -34,6 +35,16 @@ Use this chapter as a conversation prep guide for the algorithm portion of inter
 - 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.
+- **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/).
+
 ## Deep Dive Later
 - 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.

From 15382646de2f63654cc03db9cc46ce2972ad2ad8 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Fri, 31 Oct 2025 23:00:42 +0200
Subject: [PATCH 09/37] Added System Design Glossary

---
 07. System Design/overview.md               |  2 +-
 07. System Design/system_design_glossary.md | 53 +++++++++++++++++++++
 README.md                                   |  2 +
 3 files changed, 56 insertions(+), 1 deletion(-)
 create mode 100644 07. System Design/system_design_glossary.md

diff --git a/07. System Design/overview.md b/07. System Design/overview.md
index be8b263..659e00e 100644
--- a/07. System Design/overview.md	
+++ b/07. System Design/overview.md	
@@ -4,4 +4,4 @@ Explain how you balance latency, availability, and cost by applying foundational
 
 Outline request flow diagrams and component responsibilities with the [System Design Refresher](system_design_refresher.md) covering caching, load balancing, API gateways, and data layers.
 
-Collect deep dives on specific components — learn the nuances in the [Load Balancer Deep Dive](load_balancer.md), [API Gateway Deep Dive](api_gateway.md), and [Caching Strategies](caching_strategies.md); round out data sharding with the forthcoming guide.
+Collect deep dives on specific components — learn the nuances in the [Load Balancer Deep Dive](load_balancer.md), [API Gateway Deep Dive](api_gateway.md), [Caching Strategies](caching_strategies.md), and [Data Sharding & Storage Tiering](data_sharding.md); keep the [System Design Glossary](system_design_glossary.md) handy for terminology.
diff --git a/07. System Design/system_design_glossary.md b/07. System Design/system_design_glossary.md
new file mode 100644
index 0000000..b5572e7
--- /dev/null
+++ b/07. System Design/system_design_glossary.md	
@@ -0,0 +1,53 @@
+# 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.
+- **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/README.md b/README.md
index 91f0e38..2db86c9 100644
--- a/README.md
+++ b/README.md
@@ -46,6 +46,8 @@ A focused refresher for software engineers who need to get back to interview sha
 - [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)
+- Microservices Architecture _(coming soon)_
 
 ## How to Use This Repository
 - Start with **Quick Ramp-Up** when you only have a few minutes.

From de8441dffc411c9fa2334a0676735b4ce279a6e0 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sat, 1 Nov 2025 15:37:01 +0200
Subject: [PATCH 10/37] Improved overviews

---
 01. General Prep/overview.md          | 6 +++---
 02. Web Development/overview.md       | 4 ++--
 03. Backend & Frameworks/overview.md  | 6 +++---
 04. Data & Storage/overview.md        | 4 ++--
 05. Interview Strategy/overview.md    | 6 ++++--
 06. Behavioral Interviews/overview.md | 6 ++----
 07. System Design/overview.md         | 6 +++---
 7 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/01. General Prep/overview.md b/01. General Prep/overview.md
index df95a37..d732815 100644
--- a/01. General Prep/overview.md	
+++ b/01. General Prep/overview.md	
@@ -1,7 +1,7 @@
 # General Prep Overview
 
-Lead with a crisp elevator pitch (role → impact → why now) and keep three STAR stories handy for conflict, failure, and big wins; detailed prompts sit in [General interview questions](general_questions.md).
+**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).
 
-Remember that authentication proves identity (passwords, MFA, SSO) while authorization enforces least-privilege access once identity is known — sketch the login → token → permission check flow before diving into [Authentication vs Authorization](authentication_vs_authorization.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).
 
-Round things out by reviewing Git essentials: list and prune branches, explain merge vs rebase trade-offs, and practice safe cleanup with `git clean -n` before `-f`, using [Git Interview Refresh](git.md) for command specifics.
+**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/overview.md b/02. Web Development/overview.md
index 2454e31..6180148 100644
--- a/02. Web Development/overview.md	
+++ b/02. Web Development/overview.md	
@@ -1,5 +1,5 @@
 # Web Development Overview
 
-Trace an HTTP request from DNS lookup through TLS, caches/CDNs, app servers, and persistence so you can articulate latency and scaling levers — see [Web Development Interview Refresh](web_development.md) for the full walkthrough.
+**HTTP Lifecycle:** Trace DNS → TLS → CDN → app → database to explain latency and scaling decisions. Quick recap: [Web Development Interview Refresh](web_development.md).
 
-Keep JavaScript top of mind by explaining the event loop, microtasks vs macrotasks, and the difference between `preventDefault()` and `return false`, while remembering `"use strict"` quirks; drill further with [JavaScript Interview Refresh](javascript.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/03. Backend & Frameworks/overview.md b/03. Backend & Frameworks/overview.md
index af63fa9..7652865 100644
--- a/03. Backend & Frameworks/overview.md	
+++ b/03. Backend & Frameworks/overview.md	
@@ -1,7 +1,7 @@
 # Backend & Frameworks Overview
 
-Revisit Python by describing how the GIL shapes concurrency, contrasting mutable vs immutable types, and prepping quick doctest-style examples — extended notes live in [Python Interview Refresh](python.md).
+**Python Fundamentals:** Explain GIL impact, mutable vs immutable semantics, and doctest-style validation; see [Python Interview Refresh](python.md).
 
-For Django, remind yourself how `select_related` and `prefetch_related` tame query counts, how auth can be customized, and what caching or async add-ons support scaling, as captured in [Django Interview Refresh](django.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).
 
-Round out with Java: compare primitives to wrappers (autoboxing costs), outline JVM memory and GC tuning levers, and highlight concurrency utilities such as `CompletableFuture`, with more detail in [Java Interview Refresh](java.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/04. Data & Storage/overview.md b/04. Data & Storage/overview.md
index 5b2739e..a570357 100644
--- a/04. Data & Storage/overview.md	
+++ b/04. Data & Storage/overview.md	
@@ -1,5 +1,5 @@
 # Data & Storage Overview
 
-Choose relational engines based on ACID guarantees, indexing features, and workload fit (OLTP vs analytics).
+**Engine Selection:** Pick databases based on ACID guarantees, indexing strengths, and OLTP vs analytics fit — check [Database Interview Refresh](databases.md).
 
-Apply leftmost-prefix rules when designing composite indexes, and lean on `EXPLAIN` plus slow-query logs to tune performance — all captured in the [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/overview.md b/05. Interview Strategy/overview.md
index 502d482..3b49cc5 100644
--- a/05. Interview Strategy/overview.md	
+++ b/05. Interview Strategy/overview.md	
@@ -1,5 +1,7 @@
 # Interview Strategy Overview
 
-Lead algorithm discussions by stating target complexities, narrating the clarify → plan → code → test loop, and mapping problems to go-to data structures; the talking points live in [Interview Questions with Algorithmic Tasks](algorithms.md).
+**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).
 
-Use the dedicated Behavioral Interviews section for STAR storytelling materials, and the System Design section for architectural patterns once those guides are published.
+**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/overview.md b/06. Behavioral Interviews/overview.md
index 248b538..ecfbf77 100644
--- a/06. Behavioral Interviews/overview.md	
+++ b/06. Behavioral Interviews/overview.md	
@@ -1,7 +1,5 @@
 # Behavioral Interviews Overview
 
-Anchor every conversation in structured storytelling, measurable impact, and self-awareness.
+**STAR Story Crafting:** Anchor answers in Situation → Task → Action → Result, emphasize impact, and close with reflection; templates in [Behavioral Interview Playbook](behavioral_playbook.md).
 
-Practice your go-to STAR narratives for leadership, conflict, failure, and cross-functional wins in the [Behavioral Interview Playbook](behavioral_playbook.md).
-
-Build a question bank to ask interviewers about team culture, delivery cadence, and success metrics using the [Behavioral Interview Question Bank](behavioral_questions.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/overview.md b/07. System Design/overview.md
index 659e00e..7ba5d8e 100644
--- a/07. System Design/overview.md	
+++ b/07. System Design/overview.md	
@@ -1,7 +1,7 @@
 # System Design Overview
 
-Explain how you balance latency, availability, and cost by applying foundational patterns.
+**Architecture Flow:** Balance latency, availability, and cost by sketching client → edge → service → data paths; use the [System Design Refresher](system_design_refresher.md) for structured walkthroughs.
 
-Outline request flow diagrams and component responsibilities with the [System Design Refresher](system_design_refresher.md) covering caching, load balancing, API gateways, and data layers.
+**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.
 
-Collect deep dives on specific components — learn the nuances in the [Load Balancer Deep Dive](load_balancer.md), [API Gateway Deep Dive](api_gateway.md), [Caching Strategies](caching_strategies.md), and [Data Sharding & Storage Tiering](data_sharding.md); keep the [System Design Glossary](system_design_glossary.md) handy for terminology.
+**Terminology Radar:** Keep the [System Design Glossary](system_design_glossary.md) open for availability models, consistency terminology, queueing concepts, and operational vocabulary.

From 8e58fc53195a3f12003d3f0418311c1449f61791 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sat, 1 Nov 2025 15:42:11 +0200
Subject: [PATCH 11/37] Added DDoS mention + Diagram Ideas

---
 07. System Design/api_gateway.md             |  5 +++++
 07. System Design/caching_strategies.md      |  5 +++++
 07. System Design/data_sharding.md           |  5 +++++
 07. System Design/load_balancer.md           |  6 ++++++
 07. System Design/overview.md                |  2 +-
 07. System Design/system_design_refresher.md | 14 ++++++++++++--
 README.md                                    |  2 ++
 7 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/07. System Design/api_gateway.md b/07. System Design/api_gateway.md
index a893684..ae465e2 100644
--- a/07. System Design/api_gateway.md	
+++ b/07. System Design/api_gateway.md	
@@ -54,3 +54,8 @@ Highlight how API gateways centralize cross-cutting concerns, simplify client in
 - 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
index 76ba620..6921487 100644
--- a/07. System Design/caching_strategies.md	
+++ b/07. System Design/caching_strategies.md	
@@ -64,3 +64,8 @@ Explain how caches cut latency and load, manage consistency, and align with prod
 - 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.
diff --git a/07. System Design/data_sharding.md b/07. System Design/data_sharding.md
index 69e812f..b329807 100644
--- a/07. System Design/data_sharding.md	
+++ b/07. System Design/data_sharding.md	
@@ -75,3 +75,8 @@ Explain how to split and replicate data intelligently to meet growth, latency, a
 - 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.
diff --git a/07. System Design/load_balancer.md b/07. System Design/load_balancer.md
index 10413fa..24459cb 100644
--- a/07. System Design/load_balancer.md	
+++ b/07. System Design/load_balancer.md	
@@ -10,6 +10,7 @@ Use this guide to explain load balancers quickly, cover common follow-up questio
 
 ## 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).
@@ -53,3 +54,8 @@ Use this guide to explain load balancers quickly, cover common follow-up questio
 - 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.
diff --git a/07. System Design/overview.md b/07. System Design/overview.md
index 7ba5d8e..a8a218f 100644
--- a/07. System Design/overview.md	
+++ b/07. System Design/overview.md	
@@ -1,6 +1,6 @@
 # System Design Overview
 
-**Architecture Flow:** Balance latency, availability, and cost by sketching client → edge → service → data paths; use the [System Design Refresher](system_design_refresher.md) for structured walkthroughs.
+**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.
 
diff --git a/07. System Design/system_design_refresher.md b/07. System Design/system_design_refresher.md
index 42c4a5d..3a8da22 100644
--- a/07. System Design/system_design_refresher.md	
+++ b/07. System Design/system_design_refresher.md	
@@ -1,6 +1,6 @@
 # System Design Refresher
 
-Use this guide to frame architecture discussions quickly, explain trade-offs, and dive deeper into specific components when needed.
+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).
@@ -14,7 +14,7 @@ Use this guide to frame architecture discussions quickly, explain trade-offs, an
 - **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:** Touch on auth/authz, secrets management, encryption, rate limiting, and API gateway concerns.
+- **Security & Edge Defense:** Touch on auth/authz, secrets management, encryption, rate limiting, WAF/CDN-based DDoS protection, and API gateway concerns.
 
 ## Core Components
 
@@ -23,6 +23,11 @@ Use this guide to frame architecture discussions quickly, explain trade-offs, an
 - 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.
+
 ### API Gateway
 - Central entry point for client requests; handles routing, authentication, rate limiting, and request transformation.
 - Enables versioning, monetization, and observability across microservices.
@@ -47,3 +52,8 @@ Use this guide to frame architecture discussions quickly, explain trade-offs, an
 - 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 2db86c9..1f3e682 100644
--- a/README.md
+++ b/README.md
@@ -40,6 +40,7 @@ A focused refresher for software engineers who need to get back to interview sha
 - [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)
@@ -48,6 +49,7 @@ A focused refresher for software engineers who need to get back to interview sha
 - [Data Sharding & Storage Tiering](07.%20System%20Design/data_sharding.md)
 - [System Design Glossary](07.%20System%20Design/system_design_glossary.md)
 - Microservices Architecture _(coming soon)_
+- Kubernetes Operations _(coming soon)_
 
 ## How to Use This Repository
 - Start with **Quick Ramp-Up** when you only have a few minutes.

From 13ff9b5f454452bc65233e2e2bc430b1b5148fdf Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 14:44:03 +0200
Subject: [PATCH 12/37] Added Microservices Architecture and Kubernetes
 Operations

---
 07. System Design/kubernetes.md              | 48 ++++++++++++++++
 07. System Design/microservices.md           | 58 ++++++++++++++++++++
 07. System Design/system_design_refresher.md |  7 +++
 README.md                                    |  4 +-
 4 files changed, 115 insertions(+), 2 deletions(-)
 create mode 100644 07. System Design/kubernetes.md
 create mode 100644 07. System Design/microservices.md

diff --git a/07. System Design/kubernetes.md b/07. System Design/kubernetes.md
new file mode 100644
index 0000000..516717a
--- /dev/null
+++ b/07. System Design/kubernetes.md	
@@ -0,0 +1,48 @@
+# 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.
diff --git a/07. System Design/microservices.md b/07. System Design/microservices.md
new file mode 100644
index 0000000..7fd3309
--- /dev/null
+++ b/07. System Design/microservices.md	
@@ -0,0 +1,58 @@
+# 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.
+
+## 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.
diff --git a/07. System Design/system_design_refresher.md b/07. System Design/system_design_refresher.md
index 3a8da22..911a69c 100644
--- a/07. System Design/system_design_refresher.md	
+++ b/07. System Design/system_design_refresher.md	
@@ -28,6 +28,13 @@ Use this guide to frame architecture discussions quickly, explain trade-offs, an
 - 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.
+
 ### API Gateway
 - Central entry point for client requests; handles routing, authentication, rate limiting, and request transformation.
 - Enables versioning, monetization, and observability across microservices.
diff --git a/README.md b/README.md
index 1f3e682..e4b5799 100644
--- a/README.md
+++ b/README.md
@@ -48,8 +48,8 @@ Start with the refresher for the end-to-end flow (edge DDoS shield → load bala
 - [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)
-- Microservices Architecture _(coming soon)_
-- Kubernetes Operations _(coming soon)_
+- [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.

From 20779975c8134223d57886fc29344d8b6e0a670e Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 15:21:20 +0200
Subject: [PATCH 13/37] Add DDoS Response Playbook

---
 07. System Design/ddos_playbook.md           | 40 ++++++++++++++++++++
 07. System Design/system_design_refresher.md |  2 +
 README.md                                    |  1 +
 3 files changed, 43 insertions(+)
 create mode 100644 07. System Design/ddos_playbook.md

diff --git a/07. System Design/ddos_playbook.md b/07. System Design/ddos_playbook.md
new file mode 100644
index 0000000..03f6311
--- /dev/null
+++ b/07. System Design/ddos_playbook.md	
@@ -0,0 +1,40 @@
+# 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.
+- **Gateway Controls:** Increase throttling, enforce stricter authentication challenges, or degrade non-essential endpoints/features.
+- **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; consider isolating or blackholing clearly malicious segments in coordination with ISP.
+
+## 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, Azure Front Door, 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.
+
+## 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/system_design_refresher.md b/07. System Design/system_design_refresher.md
index 911a69c..c6b786e 100644
--- a/07. System Design/system_design_refresher.md	
+++ b/07. System Design/system_design_refresher.md	
@@ -35,6 +35,8 @@ Use this guide to frame architecture discussions quickly, explain trade-offs, an
 - 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.
+
 ### API Gateway
 - Central entry point for client requests; handles routing, authentication, rate limiting, and request transformation.
 - Enables versioning, monetization, and observability across microservices.
diff --git a/README.md b/README.md
index e4b5799..e8dac17 100644
--- a/README.md
+++ b/README.md
@@ -48,6 +48,7 @@ Start with the refresher for the end-to-end flow (edge DDoS shield → load bala
 - [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)
 

From fbf5718a52957b40ac03d8999405cc11c9aa2697 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 15:59:39 +0200
Subject: [PATCH 14/37] Add drafts for diagrams

---
 07. System Design/api_gateway.md              |  6 ++
 07. System Design/caching_strategies.md       |  8 +++
 07. System Design/data_sharding.md            |  4 ++
 07. System Design/ddos_playbook.md            |  6 +-
 .../diagrams/cache_read_write_sequence.md     | 34 +++++++++++
 .../diagrams/system_architecture_map.md       | 56 +++++++++++++++++++
 07. System Design/kubernetes.md               |  4 ++
 07. System Design/load_balancer.md            |  4 ++
 07. System Design/microservices.md            |  4 ++
 07. System Design/system_design_refresher.md  |  7 +++
 10 files changed, 130 insertions(+), 3 deletions(-)
 create mode 100644 07. System Design/diagrams/cache_read_write_sequence.md
 create mode 100644 07. System Design/diagrams/system_architecture_map.md

diff --git a/07. System Design/api_gateway.md b/07. System Design/api_gateway.md
index ae465e2..d3f2208 100644
--- a/07. System Design/api_gateway.md	
+++ b/07. System Design/api_gateway.md	
@@ -16,6 +16,12 @@ Highlight how API gateways centralize cross-cutting concerns, simplify client in
 - **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)
diff --git a/07. System Design/caching_strategies.md b/07. System Design/caching_strategies.md
index 6921487..518af03 100644
--- a/07. System Design/caching_strategies.md	
+++ b/07. System Design/caching_strategies.md	
@@ -69,3 +69,11 @@ Explain how caches cut latency and load, manage consistency, and align with prod
 - 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
index b329807..b248fbe 100644
--- a/07. System Design/data_sharding.md	
+++ b/07. System Design/data_sharding.md	
@@ -80,3 +80,7 @@ Explain how to split and replicate data intelligently to meet growth, latency, a
 - 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.
diff --git a/07. System Design/ddos_playbook.md b/07. System Design/ddos_playbook.md
index 03f6311..0a1438e 100644
--- a/07. System Design/ddos_playbook.md	
+++ b/07. System Design/ddos_playbook.md	
@@ -15,10 +15,10 @@ A reusable checklist for preparing, detecting, and responding to distributed den
 - **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.
-- **Gateway Controls:** Increase throttling, enforce stricter authentication challenges, or degrade non-essential endpoints/features.
+- **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; consider isolating or blackholing clearly malicious segments in coordination with ISP.
+- **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).
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..f8ba641
--- /dev/null
+++ b/07. System Design/diagrams/cache_read_write_sequence.md	
@@ -0,0 +1,34 @@
+# 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 with TTL (write)
+        note right of K: TTL = 5 min<br/>Tags = product:123
+        S-->>C: Response (fresh)
+    end
+    opt Invalidations
+        S->>K: Delete/Update cache on product change
+    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 tagging strategy during interviews; highlight idempotent writes.
+```
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..4a347a8
--- /dev/null
+++ b/07. System Design/diagrams/system_architecture_map.md	
@@ -0,0 +1,56 @@
+# System Design Architecture Map (Draft)
+
+```mermaid
+graph LR
+    subgraph Clients
+        A[Web Client]
+        B[Mobile Client]
+        C[Partner Integration]
+    end
+    A -->|HTTPS| D[DNS]
+    B -->|HTTPS| D
+    C -->|HTTPS| D
+    D --> E[CDN / WAF / DDoS Shield]
+    E -->|Cached assets| A
+    E --> F[Regional Load Balancer]
+    subgraph Services
+        G[API Gateway
+(Auth, Rate Limiting, Logging)]
+        H[Service A]
+        I[Service B]
+        J[Service C]
+    end
+    F --> G
+    G --> H
+    G --> I
+    G --> J
+    H --> K[(Cache Layer)]
+    I --> K
+    J --> L[(Message Queue / Stream)]
+    K --> M[(Databases / Object Storage)]
+    I --> M
+    J --> M
+    L --> I
+    subgraph Observability
+        N[Metrics]
+        O[Logs]
+        P[Traces]
+    end
+    H --> N
+    I --> N
+    J --> N
+    H --> O
+    I --> O
+    J --> O
+    H --> P
+    I --> P
+    J --> P
+    N --> Q[Ops Dashboards]
+    O --> Q
+    P --> Q
+```
+
+**Notes**
+- Edge layer (CDN/WAF) absorbs DDoS traffic and serves static assets; sanitized traffic flows to load balancers.
+- API gateway enforces authentication and rate limiting before routing to services.
+- Services interact with cache, message queues, and data stores while emitting observability data.
diff --git a/07. System Design/kubernetes.md b/07. System Design/kubernetes.md
index 516717a..9df7d2f 100644
--- a/07. System Design/kubernetes.md	
+++ b/07. System Design/kubernetes.md	
@@ -46,3 +46,7 @@ Refresh the essentials for deploying, scaling, and troubleshooting workloads on
 - 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.
diff --git a/07. System Design/load_balancer.md b/07. System Design/load_balancer.md
index 24459cb..1c9b093 100644
--- a/07. System Design/load_balancer.md	
+++ b/07. System Design/load_balancer.md	
@@ -59,3 +59,7 @@ Use this guide to explain load balancers quickly, cover common follow-up questio
 - 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
index 7fd3309..b90c1e8 100644
--- a/07. System Design/microservices.md	
+++ b/07. System Design/microservices.md	
@@ -56,3 +56,7 @@ Understand how to decompose, deploy, and operate services that collaborate witho
 - 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.
diff --git a/07. System Design/system_design_refresher.md b/07. System Design/system_design_refresher.md
index c6b786e..88504db 100644
--- a/07. System Design/system_design_refresher.md	
+++ b/07. System Design/system_design_refresher.md	
@@ -16,6 +16,13 @@ Use this guide to frame architecture discussions quickly, explain trade-offs, an
 - **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

From 9924a51044ea991ba9c19a8303155fa4e795b338 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:17:55 +0200
Subject: [PATCH 15/37] Fixed diagram rendering

---
 07. System Design/diagrams/system_architecture_map.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/07. System Design/diagrams/system_architecture_map.md b/07. System Design/diagrams/system_architecture_map.md
index 4a347a8..2776581 100644
--- a/07. System Design/diagrams/system_architecture_map.md	
+++ b/07. System Design/diagrams/system_architecture_map.md	
@@ -14,8 +14,7 @@ graph LR
     E -->|Cached assets| A
     E --> F[Regional Load Balancer]
     subgraph Services
-        G[API Gateway
-(Auth, Rate Limiting, Logging)]
+        G[API Gateway: Auth, Rate Limiting, Logging]
         H[Service A]
         I[Service B]
         J[Service C]

From 7d912c3d0953a14d7a35802f89529544113574e8 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:23:07 +0200
Subject: [PATCH 16/37] Make System Design Architecture Map less wide

---
 .../diagrams/system_architecture_map.md       | 56 ++++++++++++-------
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/07. System Design/diagrams/system_architecture_map.md b/07. System Design/diagrams/system_architecture_map.md
index 2776581..117a3ba 100644
--- a/07. System Design/diagrams/system_architecture_map.md	
+++ b/07. System Design/diagrams/system_architecture_map.md	
@@ -1,49 +1,65 @@
 # System Design Architecture Map (Draft)
 
 ```mermaid
-graph LR
+graph TD
     subgraph Clients
         A[Web Client]
         B[Mobile Client]
         C[Partner Integration]
     end
-    A -->|HTTPS| D[DNS]
-    B -->|HTTPS| D
-    C -->|HTTPS| D
-    D --> E[CDN / WAF / DDoS Shield]
-    E -->|Cached assets| A
-    E --> F[Regional Load Balancer]
+    subgraph Edge
+        D[DNS]
+        E[CDN / WAF / DDoS Shield]
+    end
+    subgraph Ingress
+        F[Regional Load Balancer]
+        G[API Gateway
+(Auth, Rate Limiting, Logging)]
+    end
     subgraph Services
-        G[API Gateway: Auth, Rate Limiting, Logging]
         H[Service A]
         I[Service B]
         J[Service C]
     end
+    subgraph Data & Messaging
+        K[(Cache Layer)]
+        L[(Message Queue / Stream)]
+        M[(Databases / Object Storage)]
+    end
+    subgraph Observability
+        N[Metrics]
+        O[Logs]
+        P[Traces]
+    end
+
+    A -->|HTTPS| D
+    B -->|HTTPS| D
+    C -->|HTTPS| D
+    D --> E
+    E -->|Sanitized traffic| F
     F --> G
     G --> H
     G --> I
     G --> J
-    H --> K[(Cache Layer)]
+
+    H --> K
     I --> K
-    J --> L[(Message Queue / Stream)]
-    K --> M[(Databases / Object Storage)]
+    J --> L
+    K --> M
     I --> M
     J --> M
     L --> I
-    subgraph Observability
-        N[Metrics]
-        O[Logs]
-        P[Traces]
-    end
+
     H --> N
-    I --> N
-    J --> N
     H --> O
-    I --> O
-    J --> O
     H --> P
+    I --> N
+    I --> O
     I --> P
+    J --> N
+    J --> O
     J --> P
+
     N --> Q[Ops Dashboards]
     O --> Q
     P --> Q

From 5ec2b3ee436eeaf9c668025ccf81fff72ad963ca Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:23:54 +0200
Subject: [PATCH 17/37] Fix system_architecture_map.md rendering

---
 07. System Design/diagrams/system_architecture_map.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/07. System Design/diagrams/system_architecture_map.md b/07. System Design/diagrams/system_architecture_map.md
index 117a3ba..99d147e 100644
--- a/07. System Design/diagrams/system_architecture_map.md	
+++ b/07. System Design/diagrams/system_architecture_map.md	
@@ -13,8 +13,7 @@ graph TD
     end
     subgraph Ingress
         F[Regional Load Balancer]
-        G[API Gateway
-(Auth, Rate Limiting, Logging)]
+        G[API Gateway: Auth, Rate Limiting, Logging]
     end
     subgraph Services
         H[Service A]

From b346233612f53cae93b520672e4fc1f42699feaf Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:34:16 +0200
Subject: [PATCH 18/37] Add diagram: API Gateway Request Flow

---
 .../diagrams/api_gateway_flow.md              | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 07. System Design/diagrams/api_gateway_flow.md

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..87c92f2
--- /dev/null
+++ b/07. System Design/diagrams/api_gateway_flow.md	
@@ -0,0 +1,25 @@
+# API Gateway Request Flow
+
+```mermaid
+graph TD
+    Client[Client] --> Edge[CDN / WAF]
+    Edge --> Gateway[API Gateway]
+    Gateway -->|Auth / JWT validation| AuthService[Auth Provider]
+    Gateway -->|Rate limit check| QuotaService[Quota Store]
+    Gateway --> Router{Routing Rules}
+    Router --> ServiceA[Service A (REST)]
+    Router --> ServiceB[Service B (gRPC)]
+    Router --> BFF[Mobile BFF]
+    BFF --> ServiceC[Service C]
+    ServiceA --> DB1[(DB / Cache)]
+    ServiceB --> DB2[(Message Queue / Stream)]
+    ServiceC --> DB3[(Database)]
+    Gateway --> Observability[Metrics / Logs / Traces]
+    Observability --> Ops[Ops Dashboards]
+```
+
+**Notes**
+- Edge layer (CDN/WAF) handles DDoS and basic threat detection before the gateway.
+- Gateway enforces auth and rate limits, then routes based on path/version/client.
+- Observability hooks capture metrics/logs/traces for downstream analysis.
+```

From a793088bc9bd2efbcf8d657e5fe98ff1360e48a8 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:34:24 +0200
Subject: [PATCH 19/37] Add diagram: Kubernetes Cluster Architecture

---
 .../diagrams/kubernetes_cluster.md            | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 07. System Design/diagrams/kubernetes_cluster.md

diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
new file mode 100644
index 0000000..b6943c9
--- /dev/null
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -0,0 +1,60 @@
+# Kubernetes Cluster Architecture
+
+```mermaid
+graph TD
+    subgraph Control Plane
+        APIServer[API Server]
+        Controller[Controller Manager]
+        Scheduler[Scheduler]
+        Etcd[(etcd)]
+    end
+
+    subgraph Worker Nodes
+        subgraph Node1[Worker Node]
+            Kubelet1[Kubelet]
+            Proxy1[Kube-proxy]
+            Pod1[Pod A]
+            Pod2[Pod B]
+        end
+        subgraph Node2[Worker Node]
+            Kubelet2[Kubelet]
+            Proxy2[Kube-proxy]
+            Pod3[Pod C]
+        end
+    end
+
+    ClientKubectl[kubectl / CI] -->|REST| APIServer
+    APIServer --> Controller
+    APIServer --> Scheduler
+    APIServer --> Etcd
+
+    Controller --> Kubelet1
+    Controller --> Kubelet2
+    Scheduler --> Pod1
+    Scheduler --> Pod2
+    Scheduler --> Pod3
+
+    Kubelet1 --> Pod1
+    Kubelet1 --> Pod2
+    Kubelet2 --> Pod3
+
+    subgraph Networking
+        CNI[CNI Plugin]
+        Service[Service (ClusterIP/LoadBalancer)]
+        Ingress[Ingress Controller]
+    end
+
+    CNI --> Pod1
+    CNI --> Pod2
+    CNI --> Pod3
+    Ingress --> Service
+    Service --> Pod1
+    Service --> Pod2
+    Service --> Pod3
+```
+
+**Notes**
+- Control plane components manage desired state; workers run kubelet/kube-proxy and host pods.
+- CNI provides pod networking; services and ingress expose workloads.
+- External clients interact via `kubectl`/CI pipelines hitting the API server.
+```

From 5c063f06b3e06ea20dd91ef796032504f27bd831 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:37:40 +0200
Subject: [PATCH 20/37] Explain WAF

---
 07. System Design/system_design_glossary.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/07. System Design/system_design_glossary.md b/07. System Design/system_design_glossary.md
index b5572e7..2043fc2 100644
--- a/07. System Design/system_design_glossary.md	
+++ b/07. System Design/system_design_glossary.md	
@@ -44,6 +44,7 @@ Keep these core terms at your fingertips when discussing distributed systems, re
 - **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

From 8b9f26437226abe8d90eb50180fc557efddca588 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:37:59 +0200
Subject: [PATCH 21/37] Added: Microservices Context Map

---
 .../diagrams/microservices_context.md         | 72 +++++++++++++++++++
 07. System Design/microservices.md            |  2 +
 2 files changed, 74 insertions(+)
 create mode 100644 07. System Design/diagrams/microservices_context.md

diff --git a/07. System Design/diagrams/microservices_context.md b/07. System Design/diagrams/microservices_context.md
new file mode 100644
index 0000000..31234ed
--- /dev/null
+++ b/07. System Design/diagrams/microservices_context.md	
@@ -0,0 +1,72 @@
+# Microservices Context Map
+
+```mermaid
+graph TD
+    subgraph Shared Infrastructure
+        Gateway[API Gateway]
+        Discovery[Service Discovery]
+        Observability[Observability Stack]
+    end
+
+    subgraph Catalog
+        CatalogSvc[Catalog Service]
+        InventorySvc[Inventory Service]
+        PricingSvc[Pricing Service]
+    end
+
+    subgraph Orders
+        OrderSvc[Order Service]
+        PaymentSvc[Payment Service]
+        ShippingSvc[Shipping Service]
+    end
+
+    subgraph Users
+        AuthSvc[Auth Service]
+        ProfileSvc[Profile Service]
+    end
+
+    Gateway --> CatalogSvc
+    Gateway --> OrderSvc
+    Gateway --> AuthSvc
+
+    CatalogSvc --> Discovery
+    OrderSvc --> Discovery
+    AuthSvc --> Discovery
+
+    CatalogSvc --> Observability
+    InventorySvc --> Observability
+    PricingSvc --> Observability
+    OrderSvc --> Observability
+    PaymentSvc --> Observability
+    ShippingSvc --> Observability
+    AuthSvc --> Observability
+    ProfileSvc --> Observability
+
+    CatalogSvc --> InventorySvc
+    CatalogSvc --> PricingSvc
+    OrderSvc --> PaymentSvc
+    OrderSvc --> ShippingSvc
+    OrderSvc --> InventorySvc
+    PaymentSvc --> AuthSvc
+    ProfileSvc --> AuthSvc
+
+    subgraph Data Stores
+        CatalogDB[(Catalog DB)]
+        OrderDB[(Order DB)]
+        UserDB[(User DB)]
+    end
+
+    CatalogSvc --> CatalogDB
+    InventorySvc --> CatalogDB
+    OrderSvc --> OrderDB
+    PaymentSvc --> OrderDB
+    ShippingSvc --> OrderDB
+    AuthSvc --> UserDB
+    ProfileSvc --> UserDB
+```
+
+**Notes**
+- Shared infrastructure provides gateway, discovery, and observability for bounded contexts.
+- Each bounded context (Catalog, Orders, Users) owns its data store; services communicate via APIs.
+- Highlight ownership boundaries and shared dependencies during interviews.
+```
diff --git a/07. System Design/microservices.md b/07. System Design/microservices.md
index b90c1e8..e5a0fbb 100644
--- a/07. System Design/microservices.md	
+++ b/07. System Design/microservices.md	
@@ -60,3 +60,5 @@ Understand how to decompose, deploy, and operate services that collaborate witho
 ### 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.
+
+See `diagrams/microservices_context.md` for the draft context map.

From 09cb08f3ff3365b39fc1c77cadb171677aec8353 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:41:03 +0200
Subject: [PATCH 22/37] Fixed api_gateway_flow.md rendering

---
 07. System Design/diagrams/api_gateway_flow.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/07. System Design/diagrams/api_gateway_flow.md b/07. System Design/diagrams/api_gateway_flow.md
index 87c92f2..701d32a 100644
--- a/07. System Design/diagrams/api_gateway_flow.md	
+++ b/07. System Design/diagrams/api_gateway_flow.md	
@@ -7,8 +7,8 @@ graph TD
     Gateway -->|Auth / JWT validation| AuthService[Auth Provider]
     Gateway -->|Rate limit check| QuotaService[Quota Store]
     Gateway --> Router{Routing Rules}
-    Router --> ServiceA[Service A (REST)]
-    Router --> ServiceB[Service B (gRPC)]
+    Router --> ServiceA[Service A - REST]
+    Router --> ServiceB[Service B - gRPC]
     Router --> BFF[Mobile BFF]
     BFF --> ServiceC[Service C]
     ServiceA --> DB1[(DB / Cache)]

From 4be4679ee12817fd3952742fd256f3ad968ce5ac Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:44:28 +0200
Subject: [PATCH 23/37] Update api_gateway_flow.md

---
 07. System Design/diagrams/api_gateway_flow.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/07. System Design/diagrams/api_gateway_flow.md b/07. System Design/diagrams/api_gateway_flow.md
index 701d32a..937c568 100644
--- a/07. System Design/diagrams/api_gateway_flow.md	
+++ b/07. System Design/diagrams/api_gateway_flow.md	
@@ -9,9 +9,9 @@ graph TD
     Gateway --> Router{Routing Rules}
     Router --> ServiceA[Service A - REST]
     Router --> ServiceB[Service B - gRPC]
-    Router --> BFF[Mobile BFF]
+    Router --> BFF[Mobile BFF Service]
     BFF --> ServiceC[Service C]
-    ServiceA --> DB1[(DB / Cache)]
+    ServiceA --> DB1[(Database / Cache)]
     ServiceB --> DB2[(Message Queue / Stream)]
     ServiceC --> DB3[(Database)]
     Gateway --> Observability[Metrics / Logs / Traces]
@@ -21,5 +21,5 @@ graph TD
 **Notes**
 - Edge layer (CDN/WAF) handles DDoS and basic threat detection before the gateway.
 - Gateway enforces auth and rate limits, then routes based on path/version/client.
+- Mobile BFF (Backend for Frontend) tailors responses for mobile clients before calling downstream services.
 - Observability hooks capture metrics/logs/traces for downstream analysis.
-```

From debb7259e8c89ed08295ba2a0cf753e826c06482 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 16:45:15 +0200
Subject: [PATCH 24/37] Fixed kubernetes_cluster.md rendering

---
 07. System Design/diagrams/kubernetes_cluster.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
index b6943c9..7847163 100644
--- a/07. System Design/diagrams/kubernetes_cluster.md	
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -40,7 +40,7 @@ graph TD
 
     subgraph Networking
         CNI[CNI Plugin]
-        Service[Service (ClusterIP/LoadBalancer)]
+        Service[Service - ClusterIP/LoadBalancer]
         Ingress[Ingress Controller]
     end
 

From bb4b1ec203bdc4298bd91dac0ad056db8e66a4a6 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 17:22:20 +0200
Subject: [PATCH 25/37] Make Kubernetes Cluster Architecture diagram narrower

---
 .../diagrams/kubernetes_cluster.md            | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
index 7847163..5740248 100644
--- a/07. System Design/diagrams/kubernetes_cluster.md	
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -3,6 +3,9 @@
 ```mermaid
 graph TD
     subgraph Control Plane
+    Clients[kubectl / CI Pipelines]
+
+    subgraph ControlPlane[Control Plane]
         APIServer[API Server]
         Controller[Controller Manager]
         Scheduler[Scheduler]
@@ -10,6 +13,7 @@ graph TD
     end
 
     subgraph Worker Nodes
+    subgraph WorkerPlane[Worker Nodes]
         subgraph Node1[Worker Node]
             Kubelet1[Kubelet]
             Proxy1[Kube-proxy]
@@ -21,9 +25,17 @@ graph TD
             Proxy2[Kube-proxy]
             Pod3[Pod C]
         end
+        NodeEllipsis[Other Nodes...] 
     end
 
     ClientKubectl[kubectl / CI] -->|REST| APIServer
+    subgraph Networking[Networking]
+        Ingress[Ingress Controller]
+        Service[Service (ClusterIP/LoadBalancer)]
+        CNI[CNI Plugin]
+    end
+
+    Clients -->|REST| APIServer
     APIServer --> Controller
     APIServer --> Scheduler
     APIServer --> Etcd
@@ -51,10 +63,11 @@ graph TD
     Service --> Pod1
     Service --> Pod2
     Service --> Pod3
+    CNI --> Pod1
+    CNI --> Pod2
 ```
 
 **Notes**
 - Control plane components manage desired state; workers run kubelet/kube-proxy and host pods.
-- CNI provides pod networking; services and ingress expose workloads.
-- External clients interact via `kubectl`/CI pipelines hitting the API server.
-```
+- Ingress and Services expose workloads; CNI provides pod networking.
+- External clients interact via `kubectl`/CI hitting the API server.

From c6896a412d7a732b8fc3f624af18e2fefee166a1 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 17:39:18 +0200
Subject: [PATCH 26/37] Fixed kubernetes_cluster.md

---
 .../diagrams/kubernetes_cluster.md            | 77 +++++++------------
 1 file changed, 29 insertions(+), 48 deletions(-)

diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
index 5740248..fc4d73d 100644
--- a/07. System Design/diagrams/kubernetes_cluster.md	
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -1,73 +1,54 @@
 # Kubernetes Cluster Architecture
 
 ```mermaid
-graph TD
-    subgraph Control Plane
+graph TB
     Clients[kubectl / CI Pipelines]
+    Clients -->|REST| APIServer[API Server]
 
-    subgraph ControlPlane[Control Plane]
-        APIServer[API Server]
+    subgraph Control Plane
+        APIServer
         Controller[Controller Manager]
-        Scheduler[Scheduler]
+        Scheduler
         Etcd[(etcd)]
     end
 
-    subgraph Worker Nodes
-    subgraph WorkerPlane[Worker Nodes]
-        subgraph Node1[Worker Node]
-            Kubelet1[Kubelet]
-            Proxy1[Kube-proxy]
-            Pod1[Pod A]
-            Pod2[Pod B]
-        end
-        subgraph Node2[Worker Node]
-            Kubelet2[Kubelet]
-            Proxy2[Kube-proxy]
-            Pod3[Pod C]
-        end
-        NodeEllipsis[Other Nodes...] 
-    end
-
-    ClientKubectl[kubectl / CI] -->|REST| APIServer
-    subgraph Networking[Networking]
-        Ingress[Ingress Controller]
-        Service[Service (ClusterIP/LoadBalancer)]
-        CNI[CNI Plugin]
-    end
-
-    Clients -->|REST| APIServer
     APIServer --> Controller
     APIServer --> Scheduler
     APIServer --> Etcd
 
-    Controller --> Kubelet1
-    Controller --> Kubelet2
-    Scheduler --> Pod1
-    Scheduler --> Pod2
-    Scheduler --> Pod3
+    subgraph Worker Node
+        Kubelet[Kubelet]
+        KubeProxy[Kube-proxy]
+        PodA[Pod A]
+        PodB[Pod B]
+        PodC[Pod C]
+    end
+
+    Controller --> Kubelet
+    Scheduler --> PodA
+    Scheduler --> PodB
+    Scheduler --> PodC
 
-    Kubelet1 --> Pod1
-    Kubelet1 --> Pod2
-    Kubelet2 --> Pod3
+    Kubelet --> PodA
+    Kubelet --> PodB
+    Kubelet --> PodC
 
     subgraph Networking
-        CNI[CNI Plugin]
-        Service[Service - ClusterIP/LoadBalancer]
         Ingress[Ingress Controller]
+        Service[Service (ClusterIP/LoadBalancer)]
+        CNI[CNI Plugin]
     end
 
-    CNI --> Pod1
-    CNI --> Pod2
-    CNI --> Pod3
     Ingress --> Service
-    Service --> Pod1
-    Service --> Pod2
-    Service --> Pod3
-    CNI --> Pod1
-    CNI --> Pod2
+    Service --> PodA
+    Service --> PodB
+    Service --> PodC
+    CNI --> PodA
+    CNI --> PodB
+    CNI --> PodC
 ```
 
 **Notes**
-- Control plane components manage desired state; workers run kubelet/kube-proxy and host pods.
+- Control plane components manage desired state; workers (one shown, replicated as needed) run kubelet/kube-proxy and host pods.
 - Ingress and Services expose workloads; CNI provides pod networking.
 - External clients interact via `kubectl`/CI hitting the API server.

From 6a76fcac5cc05516eaa06b3365caffd3e1790a44 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 17:48:39 +0200
Subject: [PATCH 27/37] Fix diagrams rendering

---
 07. System Design/diagrams/kubernetes_cluster.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
index fc4d73d..e51a2c6 100644
--- a/07. System Design/diagrams/kubernetes_cluster.md	
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -35,7 +35,7 @@ graph TB
 
     subgraph Networking
         Ingress[Ingress Controller]
-        Service[Service (ClusterIP/LoadBalancer)]
+        Service[Service - ClusterIP/LoadBalancer]
         CNI[CNI Plugin]
     end
 

From e7f2729d7dd3d941e8f005660d5628dbce552446 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 21:29:23 +0200
Subject: [PATCH 28/37] Add more diagrams

---
 07. System Design/data_sharding.md            |  2 ++
 .../diagrams/data_sharding_map.md             | 32 +++++++++++++++++++
 .../diagrams/kubernetes_rolling_update.md     | 23 +++++++++++++
 .../microservices_request_sequence.md         | 32 +++++++++++++++++++
 07. System Design/kubernetes.md               |  2 ++
 07. System Design/microservices.md            |  2 +-
 6 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 07. System Design/diagrams/data_sharding_map.md
 create mode 100644 07. System Design/diagrams/kubernetes_rolling_update.md
 create mode 100644 07. System Design/diagrams/microservices_request_sequence.md

diff --git a/07. System Design/data_sharding.md b/07. System Design/data_sharding.md
index b248fbe..c864680 100644
--- a/07. System Design/data_sharding.md	
+++ b/07. System Design/data_sharding.md	
@@ -84,3 +84,5 @@ Explain how to split and replicate data intelligently to meet growth, latency, a
 ### 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/diagrams/data_sharding_map.md b/07. System Design/diagrams/data_sharding_map.md
new file mode 100644
index 0000000..8203326
--- /dev/null
+++ b/07. System Design/diagrams/data_sharding_map.md	
@@ -0,0 +1,32 @@
+# Data Sharding Topology
+
+```mermaid
+graph TD
+    Client[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]
+    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
+        NewShard[Shard D Primary]
+        Router -. move tenant .-> NewShard
+        ShardAPrimary -. migrate data .-> NewShard
+    end
+```
+
+**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.
+```
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..20e7e10
--- /dev/null
+++ b/07. System Design/diagrams/kubernetes_rolling_update.md	
@@ -0,0 +1,23 @@
+# Kubernetes Rolling Update Timeline
+
+```mermaid
+gantt
+    dateFormat  X
+    axisFormat  %s
+    title Deployment Rolling Update (replicas=4, maxSurge=1, maxUnavailable=1)
+
+    section Steps
+    Drain old pod #1          :done,    0, 1
+    Launch surge pod #5       :active,  1, 1
+    Wait for readiness #5     :         2, 1
+    Route traffic to #5       :         3, 1
+    Terminate old pod #2      :         4, 1
+    Launch surge pod #6       :         5, 1
+    Readiness check #6        :         6, 1
+    Continue until pods rotated :       7, 3
+```
+
+**Notes**
+- With `maxSurge=1` and `maxUnavailable=1`, deployment keeps 4–5 pods during rollout.
+- Readiness probes must pass before shifting traffic; if they fail, rollout pauses/rolls back.
+```
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..a330ce4
--- /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)
+```
+
+**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/kubernetes.md b/07. System Design/kubernetes.md
index 9df7d2f..8a8869d 100644
--- a/07. System Design/kubernetes.md	
+++ b/07. System Design/kubernetes.md	
@@ -50,3 +50,5 @@ Refresh the essentials for deploying, scaling, and troubleshooting workloads on
 ### 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/microservices.md b/07. System Design/microservices.md
index e5a0fbb..b5785b8 100644
--- a/07. System Design/microservices.md	
+++ b/07. System Design/microservices.md	
@@ -61,4 +61,4 @@ Understand how to decompose, deploy, and operate services that collaborate witho
 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.
 
-See `diagrams/microservices_context.md` for the draft context map.
+Drafts: context map (`diagrams/microservices_context.md`) and request journey (`diagrams/microservices_request_sequence.md`).

From cfe4e4ac93e5bc56ca3f244bd0ef33bc21c4e9a9 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Sun, 2 Nov 2025 21:32:41 +0200
Subject: [PATCH 29/37] Cleanup diagrams

---
 07. System Design/diagrams/cache_read_write_sequence.md      | 1 -
 07. System Design/diagrams/data_sharding_map.md              | 1 -
 07. System Design/diagrams/kubernetes_rolling_update.md      | 1 -
 07. System Design/diagrams/microservices_context.md          | 1 -
 07. System Design/diagrams/microservices_request_sequence.md | 1 -
 5 files changed, 5 deletions(-)

diff --git a/07. System Design/diagrams/cache_read_write_sequence.md b/07. System Design/diagrams/cache_read_write_sequence.md
index f8ba641..6874aea 100644
--- a/07. System Design/diagrams/cache_read_write_sequence.md	
+++ b/07. System Design/diagrams/cache_read_write_sequence.md	
@@ -31,4 +31,3 @@ sequenceDiagram
 - 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 tagging strategy during interviews; highlight idempotent writes.
-```
diff --git a/07. System Design/diagrams/data_sharding_map.md b/07. System Design/diagrams/data_sharding_map.md
index 8203326..365b73c 100644
--- a/07. System Design/diagrams/data_sharding_map.md	
+++ b/07. System Design/diagrams/data_sharding_map.md	
@@ -29,4 +29,3 @@ graph TD
 - 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.
-```
diff --git a/07. System Design/diagrams/kubernetes_rolling_update.md b/07. System Design/diagrams/kubernetes_rolling_update.md
index 20e7e10..73ebcf0 100644
--- a/07. System Design/diagrams/kubernetes_rolling_update.md	
+++ b/07. System Design/diagrams/kubernetes_rolling_update.md	
@@ -20,4 +20,3 @@ gantt
 **Notes**
 - With `maxSurge=1` and `maxUnavailable=1`, deployment keeps 4–5 pods during rollout.
 - Readiness probes must pass before shifting traffic; if they fail, rollout pauses/rolls back.
-```
diff --git a/07. System Design/diagrams/microservices_context.md b/07. System Design/diagrams/microservices_context.md
index 31234ed..4af523d 100644
--- a/07. System Design/diagrams/microservices_context.md	
+++ b/07. System Design/diagrams/microservices_context.md	
@@ -69,4 +69,3 @@ graph TD
 - Shared infrastructure provides gateway, discovery, and observability for bounded contexts.
 - Each bounded context (Catalog, Orders, Users) owns its data store; services communicate via APIs.
 - 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
index a330ce4..b9fa024 100644
--- a/07. System Design/diagrams/microservices_request_sequence.md	
+++ b/07. System Design/diagrams/microservices_request_sequence.md	
@@ -29,4 +29,3 @@ sequenceDiagram
 **Notes**
 - Sequence mixes synchronous calls with async events; highlight tracing spans and metrics.
 - Mention saga/compensation logic if payment or inventory fails.
-```

From c4b38755a44aab0161ebfd55b0379c20d7113af0 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Tue, 4 Nov 2025 15:39:36 +0200
Subject: [PATCH 30/37] Update ddos_playbook.md

---
 07. System Design/ddos_playbook.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/07. System Design/ddos_playbook.md b/07. System Design/ddos_playbook.md
index 0a1438e..59bb40b 100644
--- a/07. System Design/ddos_playbook.md	
+++ b/07. System Design/ddos_playbook.md	
@@ -34,6 +34,12 @@ A reusable checklist for preparing, detecting, and responding to distributed den
 - **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:** Automatic detection with Route53/CloudFront integration; use AWS Firewall Manager for centralized rules.
+- **Cloudflare:** Turn on "Under Attack" mode, set zone-level rate limits, leverage Magic Transit for network-layer attacks.
+- **Google Cloud Armor:** Apply security policies with preconfigured WAF rules, enable adaptive protection for ML-based anomaly detection.
+- **Akamai:** Coordinate with SOC for scrubbing, deploy Kona site defender rules tuned to application patterns.
+
 ## Diagram Ideas
 - Timeline of detection → mitigation actions → recovery.
 - Layered architecture showing traffic flow through CDN/WAF, load balancer, services, and data stores.

From 349add1b27da04b103dec56971582d4ea7d66452 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Tue, 4 Nov 2025 16:22:56 +0200
Subject: [PATCH 31/37] Updated diagrams

---
 .../diagrams/api_gateway_flow.md              | 26 +++---
 .../diagrams/cache_read_write_sequence.md     |  8 +-
 .../diagrams/data_sharding_map.md             |  4 +-
 .../diagrams/kubernetes_cluster.md            | 21 +++--
 .../diagrams/kubernetes_rolling_update.md     | 25 +++---
 .../diagrams/load_balancer_blue_green.md      | 18 +++++
 .../diagrams/load_balancer_health.md          | 30 +++++++
 .../diagrams/microservices_context.md         | 79 ++++++++-----------
 .../microservices_request_sequence.md         |  1 +
 .../diagrams/system_architecture_map.md       | 53 +++++++------
 10 files changed, 156 insertions(+), 109 deletions(-)
 create mode 100644 07. System Design/diagrams/load_balancer_blue_green.md
 create mode 100644 07. System Design/diagrams/load_balancer_health.md

diff --git a/07. System Design/diagrams/api_gateway_flow.md b/07. System Design/diagrams/api_gateway_flow.md
index 937c568..8b57d98 100644
--- a/07. System Design/diagrams/api_gateway_flow.md	
+++ b/07. System Design/diagrams/api_gateway_flow.md	
@@ -2,24 +2,26 @@
 
 ```mermaid
 graph TD
+    classDef node fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
+
     Client[Client] --> Edge[CDN / WAF]
     Edge --> Gateway[API Gateway]
-    Gateway -->|Auth / JWT validation| AuthService[Auth Provider]
-    Gateway -->|Rate limit check| QuotaService[Quota Store]
+    Gateway -->|Auth validation| AuthProvider[Auth Provider]
+    Gateway -->|Rate limit| QuotaStore[Quota Store]
     Gateway --> Router{Routing Rules}
-    Router --> ServiceA[Service A - REST]
-    Router --> ServiceB[Service B - gRPC]
+    Router --> ServiceA[Service A]
+    Router --> ServiceB[Service B]
     Router --> BFF[Mobile BFF Service]
     BFF --> ServiceC[Service C]
-    ServiceA --> DB1[(Database / Cache)]
-    ServiceB --> DB2[(Message Queue / Stream)]
-    ServiceC --> DB3[(Database)]
+    ServiceA --> CacheDB[(Cache / Database)]
+    ServiceB --> QueueStore[(Queue / Database)]
+    ServiceC --> ServiceDB[(Database)]
     Gateway --> Observability[Metrics / Logs / Traces]
-    Observability --> Ops[Ops Dashboards]
+    Observability --> OpsDash[Ops Dashboards]
 ```
 
 **Notes**
-- Edge layer (CDN/WAF) handles DDoS and basic threat detection before the gateway.
-- Gateway enforces auth and rate limits, then routes based on path/version/client.
-- Mobile BFF (Backend for Frontend) tailors responses for mobile clients before calling downstream services.
-- Observability hooks capture metrics/logs/traces for downstream analysis.
+- 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
index 6874aea..e4bd190 100644
--- a/07. System Design/diagrams/cache_read_write_sequence.md	
+++ b/07. System Design/diagrams/cache_read_write_sequence.md	
@@ -18,16 +18,16 @@ sequenceDiagram
         K-->>S: Miss
         S->>D: Query product 123
         D-->>S: Product record
-        S->>K: Populate cache with TTL (write)
-        note right of K: TTL = 5 min<br/>Tags = product:123
+        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/Update cache on product change
+        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 tagging strategy during interviews; highlight idempotent writes.
+- 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
index 365b73c..ceee1c7 100644
--- a/07. System Design/diagrams/data_sharding_map.md	
+++ b/07. System Design/diagrams/data_sharding_map.md	
@@ -7,7 +7,7 @@ graph TD
     Router -->|Tenant B| ShardBPrimary[Shard B Primary]
     Router -->|Tenant C| ShardCPrimary[Shard C Primary]
 
-    ShardAPrimary --> ShardAReplica[Shard A Replica]
+    ShardAPrimary --> ShardAReplica[Shard A Replica] --- Note["Replication async (latency < 200ms)."]
     ShardBPrimary --> ShardBReplica[Shard B Replica]
     ShardCPrimary --> ShardCReplica[Shard C Replica]
 
@@ -28,4 +28,4 @@ graph TD
 **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.
+- 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
index e51a2c6..1cb5927 100644
--- a/07. System Design/diagrams/kubernetes_cluster.md	
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -2,10 +2,9 @@
 
 ```mermaid
 graph TB
-    Clients[kubectl / CI Pipelines]
-    Clients -->|REST| APIServer[API Server]
+    Clients[kubectl / CI Pipelines] -->|REST| APIServer[API Server]
 
-    subgraph Control Plane
+    subgraph ControlPlane[Control Plane]
         APIServer
         Controller[Controller Manager]
         Scheduler
@@ -16,7 +15,7 @@ graph TB
     APIServer --> Scheduler
     APIServer --> Etcd
 
-    subgraph Worker Node
+    subgraph WorkerNodes[Worker Nodes (representative)]
         Kubelet[Kubelet]
         KubeProxy[Kube-proxy]
         PodA[Pod A]
@@ -33,9 +32,9 @@ graph TB
     Kubelet --> PodB
     Kubelet --> PodC
 
-    subgraph Networking
+    subgraph Networking[Networking]
         Ingress[Ingress Controller]
-        Service[Service - ClusterIP/LoadBalancer]
+        Service[Service (ClusterIP/LoadBalancer)]
         CNI[CNI Plugin]
     end
 
@@ -43,12 +42,12 @@ graph TB
     Service --> PodA
     Service --> PodB
     Service --> PodC
-    CNI --> PodA
-    CNI --> PodB
-    CNI --> PodC
+    CNI <-->|Pod networking| PodA
+    CNI <-->|Pod networking| PodB
+    CNI <-->|Pod networking| PodC
 ```
 
 **Notes**
-- Control plane components manage desired state; workers (one shown, replicated as needed) run kubelet/kube-proxy and host pods.
-- Ingress and Services expose workloads; CNI provides pod networking.
+- 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
index 73ebcf0..2b02a05 100644
--- a/07. System Design/diagrams/kubernetes_rolling_update.md	
+++ b/07. System Design/diagrams/kubernetes_rolling_update.md	
@@ -2,21 +2,22 @@
 
 ```mermaid
 gantt
+    title Deployment Rolling Update
     dateFormat  X
     axisFormat  %s
-    title Deployment Rolling Update (replicas=4, maxSurge=1, maxUnavailable=1)
 
-    section Steps
-    Drain old pod #1          :done,    0, 1
-    Launch surge pod #5       :active,  1, 1
-    Wait for readiness #5     :         2, 1
-    Route traffic to #5       :         3, 1
-    Terminate old pod #2      :         4, 1
-    Launch surge pod #6       :         5, 1
-    Readiness check #6        :         6, 1
-    Continue until pods rotated :       7, 3
+    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**
-- With `maxSurge=1` and `maxUnavailable=1`, deployment keeps 4–5 pods during rollout.
-- Readiness probes must pass before shifting traffic; if they fail, rollout pauses/rolls back.
+- `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
index 4af523d..f6a8031 100644
--- a/07. System Design/diagrams/microservices_context.md	
+++ b/07. System Design/diagrams/microservices_context.md	
@@ -1,71 +1,58 @@
 # Microservices Context Map
 
 ```mermaid
-graph TD
+graph TB
     subgraph Shared Infrastructure
         Gateway[API Gateway]
         Discovery[Service Discovery]
         Observability[Observability Stack]
     end
 
-    subgraph Catalog
-        CatalogSvc[Catalog Service]
-        InventorySvc[Inventory Service]
-        PricingSvc[Pricing Service]
+    subgraph Catalog Context
+        CatalogService[Catalog Service]
+        InventoryService[Inventory Service]
+        PricingService[Pricing Service]
+        CatalogDB[(Catalog DB)]
     end
 
-    subgraph Orders
-        OrderSvc[Order Service]
-        PaymentSvc[Payment Service]
-        ShippingSvc[Shipping Service]
+    subgraph Orders Context
+        OrderService[Order Service]
+        PaymentService[Payment Service]
+        ShippingService[Shipping Service]
+        OrderDB[(Order DB)]
     end
 
-    subgraph Users
-        AuthSvc[Auth Service]
-        ProfileSvc[Profile Service]
+    subgraph Users Context
+        AuthService[Auth Service]
+        ProfileService[Profile Service]
+        UserDB[(User DB)]
     end
 
-    Gateway --> CatalogSvc
-    Gateway --> OrderSvc
-    Gateway --> AuthSvc
+    Gateway --> CatalogService
+    Gateway --> OrderService
+    Gateway --> AuthService
 
-    CatalogSvc --> Discovery
-    OrderSvc --> Discovery
-    AuthSvc --> Discovery
+    CatalogService --> Discovery
+    OrderService --> Discovery
+    AuthService --> Discovery
 
-    CatalogSvc --> Observability
-    InventorySvc --> Observability
-    PricingSvc --> Observability
-    OrderSvc --> Observability
-    PaymentSvc --> Observability
-    ShippingSvc --> Observability
-    AuthSvc --> Observability
-    ProfileSvc --> Observability
+    CatalogService --> Observability
+    OrderService --> Observability
+    AuthService --> Observability
 
-    CatalogSvc --> InventorySvc
-    CatalogSvc --> PricingSvc
-    OrderSvc --> PaymentSvc
-    OrderSvc --> ShippingSvc
-    OrderSvc --> InventorySvc
-    PaymentSvc --> AuthSvc
-    ProfileSvc --> AuthSvc
+    CatalogService --> CatalogDB
+    InventoryService --> CatalogDB
+    PricingService --> CatalogDB
 
-    subgraph Data Stores
-        CatalogDB[(Catalog DB)]
-        OrderDB[(Order DB)]
-        UserDB[(User DB)]
-    end
+    OrderService --> OrderDB
+    PaymentService --> OrderDB
+    ShippingService --> OrderDB
 
-    CatalogSvc --> CatalogDB
-    InventorySvc --> CatalogDB
-    OrderSvc --> OrderDB
-    PaymentSvc --> OrderDB
-    ShippingSvc --> OrderDB
-    AuthSvc --> UserDB
-    ProfileSvc --> UserDB
+    AuthService --> UserDB
+    ProfileService --> UserDB
 ```
 
 **Notes**
 - Shared infrastructure provides gateway, discovery, and observability for bounded contexts.
-- Each bounded context (Catalog, Orders, Users) owns its data store; services communicate via APIs.
+- 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
index b9fa024..429a65d 100644
--- a/07. System Design/diagrams/microservices_request_sequence.md	
+++ b/07. System Design/diagrams/microservices_request_sequence.md	
@@ -24,6 +24,7 @@ sequenceDiagram
     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**
diff --git a/07. System Design/diagrams/system_architecture_map.md b/07. System Design/diagrams/system_architecture_map.md
index 99d147e..ce02d4c 100644
--- a/07. System Design/diagrams/system_architecture_map.md	
+++ b/07. System Design/diagrams/system_architecture_map.md	
@@ -1,7 +1,11 @@
-# System Design Architecture Map (Draft)
+# System Design Architecture Map
 
 ```mermaid
-graph TD
+graph TB
+    classDef sync fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
+    classDef async fill:#fff3e0,stroke:#ef6c00,color:#bf360c;
+    classDef data fill:#f1f8e9,stroke:#33691e,color:#1b5e20;
+
     subgraph Clients
         A[Web Client]
         B[Mobile Client]
@@ -9,33 +13,34 @@ graph TD
     end
     subgraph Edge
         D[DNS]
-        E[CDN / WAF / DDoS Shield]
+        E[CDN / WAF]
     end
     subgraph Ingress
-        F[Regional Load Balancer]
-        G[API Gateway: Auth, Rate Limiting, Logging]
+        F[Load Balancer]
+        G[API Gateway]
     end
     subgraph Services
         H[Service A]
         I[Service B]
         J[Service C]
     end
-    subgraph Data & Messaging
-        K[(Cache Layer)]
-        L[(Message Queue / Stream)]
-        M[(Databases / Object Storage)]
+    subgraph Data
+        K[(Cache)]
+        L[(Database)]
+        M[(Queue)]
     end
     subgraph Observability
         N[Metrics]
         O[Logs]
         P[Traces]
     end
+    Q[Ops Dashboards]
 
-    A -->|HTTPS| D
-    B -->|HTTPS| D
-    C -->|HTTPS| D
+    A --> D
+    B --> D
+    C --> D
     D --> E
-    E -->|Sanitized traffic| F
+    E --> F
     F --> G
     G --> H
     G --> I
@@ -43,11 +48,10 @@ graph TD
 
     H --> K
     I --> K
-    J --> L
-    K --> M
-    I --> M
+    H --> L
+    I --> L
     J --> M
-    L --> I
+    M --> I
 
     H --> N
     H --> O
@@ -59,12 +63,17 @@ graph TD
     J --> O
     J --> P
 
-    N --> Q[Ops Dashboards]
+    N --> Q
     O --> Q
     P --> Q
+
+    class H,I sync;
+    class J async;
+    class K,L,M data;
 ```
 
-**Notes**
-- Edge layer (CDN/WAF) absorbs DDoS traffic and serves static assets; sanitized traffic flows to load balancers.
-- API gateway enforces authentication and rate limiting before routing to services.
-- Services interact with cache, message queues, and data stores while emitting observability data.
+**Legend**
+- Sync Service: Service A / Service B
+- Async Service: Service C (Queue)
+- Data Stores: Cache, Database, Queue
+- Observability: Metrics, Logs, Traces feeding Ops dashboards

From e4272f9d29d33a782e00b9555be5f5ac142008f3 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Tue, 4 Nov 2025 16:44:15 +0200
Subject: [PATCH 32/37] Fixed links and added links for system Design

---
 05. Interview Strategy/overview.md           |  4 +-
 07. System Design/microservices.md           |  2 +
 07. System Design/system_design_refresher.md |  2 +
 README.md                                    | 56 ++++++++++----------
 4 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/05. Interview Strategy/overview.md b/05. Interview Strategy/overview.md
index 3b49cc5..b1839f3 100644
--- a/05. Interview Strategy/overview.md	
+++ b/05. Interview Strategy/overview.md	
@@ -2,6 +2,6 @@
 
 **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.
+**Behavioral Playbook:** Jump to [Behavioral Interviews](../06. Behavioral Interviews/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.
+**System Design:** Leverage [System Design](../07. System Design/overview.md) for architectural flows, component deep dives, and glossary refreshers.
diff --git a/07. System Design/microservices.md b/07. System Design/microservices.md
index b5785b8..bb83156 100644
--- a/07. System Design/microservices.md	
+++ b/07. System Design/microservices.md	
@@ -52,6 +52,8 @@ Understand how to decompose, deploy, and operate services that collaborate witho
 - 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.
diff --git a/07. System Design/system_design_refresher.md b/07. System Design/system_design_refresher.md
index 88504db..be66565 100644
--- a/07. System Design/system_design_refresher.md	
+++ b/07. System Design/system_design_refresher.md	
@@ -44,6 +44,8 @@ Use this guide to frame architecture discussions quickly, explain trade-offs, an
 
 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.
diff --git a/README.md b/README.md
index e8dac17..1d66dc3 100644
--- a/README.md
+++ b/README.md
@@ -10,47 +10,47 @@ A focused refresher for software engineers who need to get back to interview sha
 ## Table of Contents
 
 ### 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)
+- [Overview](01. General Prep/overview.md)
+- [General interview questions](01. General Prep/general_questions.md)
+- [Authentication vs Authorization](01. General Prep/authentication_vs_authorization.md)
+- [Git](01. General Prep/git.md)
 
 ### 02. Web Development
-- [Overview](02.%20Web%20Development/overview.md)
-- [Web development](02.%20Web%20Development/web_development.md)
-- [JavaScript](02.%20Web%20Development/javascript.md)
+- [Overview](02. Web Development/overview.md)
+- [Web development](02. Web Development/web_development.md)
+- [JavaScript](02. Web Development/javascript.md)
 
 ### 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)
+- [Overview](03. Backend %26 Frameworks/overview.md)
+- [Python](03. Backend %26 Frameworks/python.md)
+- [Django](03. Backend %26 Frameworks/django.md)
+- [Java](03. Backend %26 Frameworks/java.md)
 
 ### 04. Data & Storage
-- [Overview](04.%20Data%20%26%20Storage/overview.md)
-- [Databases](04.%20Data%20%26%20Storage/databases.md)
+- [Overview](04. Data %26 Storage/overview.md)
+- [Databases](04. Data %26 Storage/databases.md)
 
 ### 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.
+- [Overview](05. Interview Strategy/overview.md)
+- [Algorithmic questions](05. Interview Strategy/algorithms.md) — high-level framing; defer detailed practice to the dedicated Algorithms & Data Structures repo.
 
 ### 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)
+- [Overview](06. Behavioral Interviews/overview.md)
+- [Behavioral Interview Playbook](06. Behavioral Interviews/behavioral_playbook.md)
+- [Behavioral Interview Question Bank](06. Behavioral Interviews/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)
+- [Overview](07. System Design/overview.md)
+- [System Design Refresher](07. System Design/system_design_refresher.md)
+- [Load Balancer Deep Dive](07. System Design/load_balancer.md)
+- [API Gateway Deep Dive](07. System Design/api_gateway.md)
+- [Caching Strategies](07. System Design/caching_strategies.md)
+- [Data Sharding & Storage Tiering](07. System Design/data_sharding.md)
+- [System Design Glossary](07. System Design/system_design_glossary.md)
+- [DDoS Response Playbook](07. System Design/ddos_playbook.md)
+- [Microservices Architecture](07. System Design/microservices.md)
+- [Kubernetes Operations](07. System Design/kubernetes.md)
 
 ## How to Use This Repository
 - Start with **Quick Ramp-Up** when you only have a few minutes.

From 7daf3fc25c9ae10bb1a2b83f2c7231b10a9815e7 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Tue, 4 Nov 2025 16:47:32 +0200
Subject: [PATCH 33/37] Fix links (revert last change)

---
 05. Interview Strategy/overview.md |  4 +--
 README.md                          | 56 +++++++++++++++---------------
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/05. Interview Strategy/overview.md b/05. Interview Strategy/overview.md
index b1839f3..3b49cc5 100644
--- a/05. Interview Strategy/overview.md	
+++ b/05. Interview Strategy/overview.md	
@@ -2,6 +2,6 @@
 
 **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. Behavioral Interviews/overview.md) for STAR storytelling guides and question banks.
+**Behavioral Playbook:** Jump to [Behavioral Interviews](../06.%20Behavioral%20Interviews/overview.md) for STAR storytelling guides and question banks.
 
-**System Design:** Leverage [System Design](../07. System Design/overview.md) for architectural flows, component deep dives, and glossary refreshers.
+**System Design:** Leverage [System Design](../07.%20System%20Design/overview.md) for architectural flows, component deep dives, and glossary refreshers.
diff --git a/README.md b/README.md
index 1d66dc3..e8dac17 100644
--- a/README.md
+++ b/README.md
@@ -10,47 +10,47 @@ A focused refresher for software engineers who need to get back to interview sha
 ## Table of Contents
 
 ### 01. General Prep
-- [Overview](01. General Prep/overview.md)
-- [General interview questions](01. General Prep/general_questions.md)
-- [Authentication vs Authorization](01. General Prep/authentication_vs_authorization.md)
-- [Git](01. General Prep/git.md)
+- [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)
 
 ### 02. Web Development
-- [Overview](02. Web Development/overview.md)
-- [Web development](02. Web Development/web_development.md)
-- [JavaScript](02. Web Development/javascript.md)
+- [Overview](02.%20Web%20Development/overview.md)
+- [Web development](02.%20Web%20Development/web_development.md)
+- [JavaScript](02.%20Web%20Development/javascript.md)
 
 ### 03. Backend & Frameworks
-- [Overview](03. Backend %26 Frameworks/overview.md)
-- [Python](03. Backend %26 Frameworks/python.md)
-- [Django](03. Backend %26 Frameworks/django.md)
-- [Java](03. Backend %26 Frameworks/java.md)
+- [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)
 
 ### 04. Data & Storage
-- [Overview](04. Data %26 Storage/overview.md)
-- [Databases](04. Data %26 Storage/databases.md)
+- [Overview](04.%20Data%20%26%20Storage/overview.md)
+- [Databases](04.%20Data%20%26%20Storage/databases.md)
 
 ### 05. Interview Strategy
-- [Overview](05. Interview Strategy/overview.md)
-- [Algorithmic questions](05. Interview Strategy/algorithms.md) — high-level framing; defer detailed practice to the dedicated Algorithms & Data Structures repo.
+- [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.
 
 ### 06. Behavioral Interviews
-- [Overview](06. Behavioral Interviews/overview.md)
-- [Behavioral Interview Playbook](06. Behavioral Interviews/behavioral_playbook.md)
-- [Behavioral Interview Question Bank](06. Behavioral Interviews/behavioral_questions.md)
+- [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. System Design/overview.md)
-- [System Design Refresher](07. System Design/system_design_refresher.md)
-- [Load Balancer Deep Dive](07. System Design/load_balancer.md)
-- [API Gateway Deep Dive](07. System Design/api_gateway.md)
-- [Caching Strategies](07. System Design/caching_strategies.md)
-- [Data Sharding & Storage Tiering](07. System Design/data_sharding.md)
-- [System Design Glossary](07. System Design/system_design_glossary.md)
-- [DDoS Response Playbook](07. System Design/ddos_playbook.md)
-- [Microservices Architecture](07. System Design/microservices.md)
-- [Kubernetes Operations](07. System Design/kubernetes.md)
+- [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.

From 7a34c0ba101d6baeb1029830a80c4de96a4c7173 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Tue, 4 Nov 2025 16:55:50 +0200
Subject: [PATCH 34/37] Polished DDoS Playbook

---
 07. System Design/ddos_playbook.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/07. System Design/ddos_playbook.md b/07. System Design/ddos_playbook.md
index 59bb40b..ce8d11b 100644
--- a/07. System Design/ddos_playbook.md	
+++ b/07. System Design/ddos_playbook.md	
@@ -30,15 +30,16 @@ A reusable checklist for preparing, detecting, and responding to distributed den
 - **Follow-Up:** File action items (automation, tooling improvements, provider contracts, playbook refinements) and schedule a blameless postmortem review.
 
 ## References & Tooling
-- **Providers:** AWS Shield/CloudFront, Azure Front Door, Google Cloud Armor, Cloudflare, Akamai Kona.
+- **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:** Automatic detection with Route53/CloudFront integration; use AWS Firewall Manager for centralized rules.
-- **Cloudflare:** Turn on "Under Attack" mode, set zone-level rate limits, leverage Magic Transit for network-layer attacks.
-- **Google Cloud Armor:** Apply security policies with preconfigured WAF rules, enable adaptive protection for ML-based anomaly detection.
-- **Akamai:** Coordinate with SOC for scrubbing, deploy Kona site defender rules tuned to application patterns.
+- **Cloudflare:** Enable "Under Attack" mode, set zone-level rate limits, leverage Magic Transit for network-layer attacks.
+- **Google Cloud Armor:** Apply security policies with preconfigured WAF rules, enable adaptive protection for anomaly detection.
+- **Azure Front Door:** Configure WAF managed rules, rate limits, and Azure DDoS Protection Standard for volumetric attacks.
+- **Akamai Kona:** Coordinate with Akamai SOC for scrubbing; deploy tuned Kona Site Defender policies aligned with application patterns.
 
 ## Diagram Ideas
 - Timeline of detection → mitigation actions → recovery.

From 865a9eaeb414c132dab55dde3233cc491bbd60d0 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Tue, 4 Nov 2025 22:50:17 +0200
Subject: [PATCH 35/37] Update algorithms.md

---
 05. Interview Strategy/algorithms.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/05. Interview Strategy/algorithms.md b/05. Interview Strategy/algorithms.md
index d461610..6ecdcb5 100644
--- a/05. Interview Strategy/algorithms.md	
+++ b/05. Interview Strategy/algorithms.md	
@@ -2,6 +2,12 @@
 
 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/).
 
+## Quick Practice Loop
+- Pick one medium-level problem, spend 5 minutes clarifying constraints before touching the keyboard.
+- Pseudocode aloud, then solve in your preferred language; timebox to 20 minutes.
+- Debrief: compare with editorial/solutions, capture new patterns in spaced notes.
+- Log the session in the external repo (or a journal) so you can revisit trends and progress.
+
 ## 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.
@@ -46,6 +52,7 @@ Use this chapter as a conversation prep guide for the algorithm portion of inter
 - **Learning loop:** Tie the outcome back to prior practice — reference similar problems from the [Algorithms & Data Structures repository](https://github.com/1st/algorithms/).
 
 ## 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.

From 8dfaf47c8cc7c8a11bd351e268edda9dc84db8ee Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Wed, 5 Nov 2025 12:18:36 +0200
Subject: [PATCH 36/37] Enhance interview and system design docs, update
 diagrams

Expanded interview algorithm prep guidance and reframed practice loops for clarity. Updated DDoS provider playbook with more actionable, provider-specific incident steps. Improved all system design diagrams with Mermaid class definitions for better visual distinction of components, added direction hints, and clarified node roles for easier reading and presentation.
---
 05. Interview Strategy/algorithms.md          | 24 ++++++++++---------
 07. System Design/ddos_playbook.md            | 10 ++++----
 .../diagrams/api_gateway_flow.md              | 12 +++++++++-
 .../diagrams/data_sharding_map.md             | 23 ++++++++++++++----
 .../diagrams/kubernetes_cluster.md            | 13 ++++++++++
 .../diagrams/microservices_context.md         | 12 ++++++++++
 .../diagrams/system_architecture_map.md       | 12 ++++++++--
 7 files changed, 83 insertions(+), 23 deletions(-)

diff --git a/05. Interview Strategy/algorithms.md b/05. Interview Strategy/algorithms.md
index 6ecdcb5..20deb7c 100644
--- a/05. Interview Strategy/algorithms.md	
+++ b/05. Interview Strategy/algorithms.md	
@@ -1,12 +1,14 @@
 # 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/).
+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, spend 5 minutes clarifying constraints before touching the keyboard.
-- Pseudocode aloud, then solve in your preferred language; timebox to 20 minutes.
-- Debrief: compare with editorial/solutions, capture new patterns in spaced notes.
-- Log the session in the external repo (or a journal) so you can revisit trends and progress.
+- 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.
@@ -14,10 +16,10 @@ Use this chapter as a conversation prep guide for the algorithm portion of inter
 - 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.
 
-## Quick Refresh
-- Recall how to describe time and space complexity using Big O, and rehearse concise definitions for `O(1)`, `O(n log n)`, and `O(n^2)`.
-- Be ready to narrate your problem-solving process: clarify requirements, outline approach, validate with examples, and discuss trade-offs.
-- Keep a short list of go-to data structures (arrays, hash maps, stacks/queues, trees/graphs) and what problems they fit.
+## 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
 
@@ -43,13 +45,13 @@ Use this chapter as a conversation prep guide for the algorithm portion of inter
 
 ## 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.
+- **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/).
+- **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.
diff --git a/07. System Design/ddos_playbook.md b/07. System Design/ddos_playbook.md
index ce8d11b..0344ef6 100644
--- a/07. System Design/ddos_playbook.md	
+++ b/07. System Design/ddos_playbook.md	
@@ -35,11 +35,11 @@ A reusable checklist for preparing, detecting, and responding to distributed den
 - **Testing:** DDoS simulation platforms, load-testing tools (k6, Locust), chaos engineering frameworks.
 
 ## Provider Quick Notes
-- **AWS Shield Advanced:** Automatic detection with Route53/CloudFront integration; use AWS Firewall Manager for centralized rules.
-- **Cloudflare:** Enable "Under Attack" mode, set zone-level rate limits, leverage Magic Transit for network-layer attacks.
-- **Google Cloud Armor:** Apply security policies with preconfigured WAF rules, enable adaptive protection for anomaly detection.
-- **Azure Front Door:** Configure WAF managed rules, rate limits, and Azure DDoS Protection Standard for volumetric attacks.
-- **Akamai Kona:** Coordinate with Akamai SOC for scrubbing; deploy tuned Kona Site Defender policies aligned with application patterns.
+- **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.
diff --git a/07. System Design/diagrams/api_gateway_flow.md b/07. System Design/diagrams/api_gateway_flow.md
index 8b57d98..fa7ee6b 100644
--- a/07. System Design/diagrams/api_gateway_flow.md	
+++ b/07. System Design/diagrams/api_gateway_flow.md	
@@ -2,7 +2,11 @@
 
 ```mermaid
 graph TD
-    classDef node fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
+    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]
@@ -18,6 +22,12 @@ graph TD
     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**
diff --git a/07. System Design/diagrams/data_sharding_map.md b/07. System Design/diagrams/data_sharding_map.md
index ceee1c7..58e7298 100644
--- a/07. System Design/diagrams/data_sharding_map.md	
+++ b/07. System Design/diagrams/data_sharding_map.md	
@@ -2,7 +2,14 @@
 
 ```mermaid
 graph TD
-    Client[Service] --> Router[Shard Router / Metadata Service]
+    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]
@@ -11,18 +18,26 @@ graph TD
     ShardBPrimary --> ShardBReplica[Shard B Replica]
     ShardCPrimary --> ShardCReplica[Shard C Replica]
 
-    ShardAPrimary --> MonitoringA[Metrics/Logs]
-    ShardBPrimary --> MonitoringB[Metrics/Logs]
-    ShardCPrimary --> MonitoringC[Metrics/Logs]
+    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**
diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
index 1cb5927..483a99e 100644
--- a/07. System Design/diagrams/kubernetes_cluster.md	
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -2,9 +2,15 @@
 
 ```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
@@ -16,6 +22,7 @@ graph TB
     APIServer --> Etcd
 
     subgraph WorkerNodes[Worker Nodes (representative)]
+        direction TB
         Kubelet[Kubelet]
         KubeProxy[Kube-proxy]
         PodA[Pod A]
@@ -33,6 +40,7 @@ graph TB
     Kubelet --> PodC
 
     subgraph Networking[Networking]
+        direction TB
         Ingress[Ingress Controller]
         Service[Service (ClusterIP/LoadBalancer)]
         CNI[CNI Plugin]
@@ -45,6 +53,11 @@ graph TB
     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**
diff --git a/07. System Design/diagrams/microservices_context.md b/07. System Design/diagrams/microservices_context.md
index f6a8031..9296d6c 100644
--- a/07. System Design/diagrams/microservices_context.md	
+++ b/07. System Design/diagrams/microservices_context.md	
@@ -2,13 +2,19 @@
 
 ```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]
@@ -16,6 +22,7 @@ graph TB
     end
 
     subgraph Orders Context
+        direction TB
         OrderService[Order Service]
         PaymentService[Payment Service]
         ShippingService[Shipping Service]
@@ -23,6 +30,7 @@ graph TB
     end
 
     subgraph Users Context
+        direction TB
         AuthService[Auth Service]
         ProfileService[Profile Service]
         UserDB[(User DB)]
@@ -50,6 +58,10 @@ graph TB
 
     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**
diff --git a/07. System Design/diagrams/system_architecture_map.md b/07. System Design/diagrams/system_architecture_map.md
index ce02d4c..c4a040c 100644
--- a/07. System Design/diagrams/system_architecture_map.md	
+++ b/07. System Design/diagrams/system_architecture_map.md	
@@ -2,9 +2,13 @@
 
 ```mermaid
 graph TB
-    classDef sync fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
-    classDef async fill:#fff3e0,stroke:#ef6c00,color:#bf360c;
+    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]
@@ -70,6 +74,10 @@ graph TB
     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**

From e4c8b0d1e77b75b6b275cac201c17145df30ee76 Mon Sep 17 00:00:00 2001
From: Anton Danylchenko <anton.danilchenko@gmail.com>
Date: Wed, 5 Nov 2025 12:21:01 +0200
Subject: [PATCH 37/37] Fixed some diagrams to render correctly

---
 07. System Design/diagrams/kubernetes_cluster.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/07. System Design/diagrams/kubernetes_cluster.md b/07. System Design/diagrams/kubernetes_cluster.md
index 483a99e..1d37608 100644
--- a/07. System Design/diagrams/kubernetes_cluster.md	
+++ b/07. System Design/diagrams/kubernetes_cluster.md	
@@ -21,7 +21,7 @@ graph TB
     APIServer --> Scheduler
     APIServer --> Etcd
 
-    subgraph WorkerNodes[Worker Nodes (representative)]
+    subgraph WorkerNodes[Worker Nodes - representative]
         direction TB
         Kubelet[Kubelet]
         KubeProxy[Kube-proxy]
@@ -42,7 +42,7 @@ graph TB
     subgraph Networking[Networking]
         direction TB
         Ingress[Ingress Controller]
-        Service[Service (ClusterIP/LoadBalancer)]
+        Service[Service - ClusterIP/LoadBalancer]
         CNI[CNI Plugin]
     end