# Remember: The simplest solution that solves your problem is usually the best one.

# Mục lục

- [I. Database](#Database)
- [x] [1. How does SQL store and query data?](#1-How-does-SQL-store-and-query-data)
- [x] [2. How index of MySQL is implemented?](#2-How-index-of-MySQL-is-implemented)
- [ ] [3. Difference and advantages of B+Tree comparing to BTree?](#3-Difference-and-advantages-of-BTree-comparing-to-BTree)
- [ ] [4. How to install tree in database](#4-How-to-install-tree-in-database)
- [x] [5. ACID in Database how the database make sure atomic feature?](#5-ACID-in-Database-how-the-database-make-sure-atomic-feature)
- [x] [6. Database Isolation(4 levels), what are they and what are the difference between them?](#6-Database-Isolation4-levels-what-are-they-and-what-are-the-difference-between-them)
- [x] [7. Index types in database (tips javascipt), when to use it](#7-Index-types-in-database-tips-javascipt-when-to-use-it)
- [x] [8. Advantages and disadvantages of DB Indexing?](#8-Advantages-and-disadvantages-of-DB-Indexing)
- [ ] [9. n+1 problems](#9-n1-problems)
- [ ] [10. Đã dùng NoSQL bao giờ chưa, điểm mạnh của NoSQL hơn so với RDBMS là gì? RDBMS có thể scale được không? Có thể có nhiều master cho RDBMS không?](#10-Đã-dùng-NoSQL-bao-giờ-chưa-điểm-mạnh-của-NoSQL-hơn-so-với-RDBMS-là-gì-RDBMS-có-thể-scale-được-không-Có-thể-có-nhiều-master-cho-RDBMS-không)
- [x] [11. Tại sao các ngân hàng và hệ thống lớn thường sử dụng Oracle thay vì SQL Server?](#11-Tại-sao-các-ngân-hàng-và-hệ-thống-lớn-thường-sử-dụng-Oracle-thay-vì-SQL-Server)
- [x] [12. Quá trình thực hiện một câu query](#12-Quá-trình-thực-hiện-một-câu-query)
- [x] [13. Các bước tối ưu performance (xem lại)](#13-Các-bước-tối-ưu-performance-xem-lại)
- [ ] [14. CAP theorem](#14-CAP-theorem)
- [ ] [15. Các dạng chuẩn (Normalization) 1NF, 2NF, 3NF, Boyy-Code](#15-Các-dạng-chuẩn-Normalization)
- [II. Security](#Security)
- [x] [1. Thuật toán mã hóa AES và RSA](#1-Thuật-toán-mã-hóa-AES-và-RSA)
- [x] [2. SSL/TLS/HTTPS?](#2-SSLTLSHTTPS)
- [x] [3. What happens when you type URL into your browser?](#3-What-happens-when-you-type-URL-into-your-browser)

- [III. Network](#Network)
- [ ] [1. HTTP/TCP/UDP](#1-SSLTLSHTTPS)
- [x] [2. So sánh HTTP 1, 1.1, 2 và 3](#2-So-sánh-HTTP-1-11-2-và-3)
- [ ] [3. So sánh websocket và HTTP, websocket xài giao thức nào](#3-So-sánh-websocket-và-HTTP-websocket-xài-giao-thức-nào)
- [ ] [4. OSI 7 layers](#4-OSI-7-layers)

- [IV. Programming](#Programming)
- [x] [1. Process vs Thread](#1-Process-vs-Thread)
- [ ] [2. Concurrency vs Parallelism: Are they the same or different?](#2-Concurrency-vs-Parallelism-Are-they-the-same-or-different)
- [x] [3. LinkedList vs. ArrayList (Java implement) (reformat)](#3-LinkedList-vs-ArrayList-Java-implement)
- [x] [4. How HashMap is implemented? (Java implement)](#4-How-HashMap-is-implemented-Java-implement)
- [ ] [5. How do computers understand your code? ](#5-How-do-computers-understand-your-code)
- [x] [6. Chiến lược cache, invalidate cache](#6-Chiến-lược-cache-invalidate-cache)
- [ ] [7. race condition](#7-race-condition)
- [x] [8. What’s RESTful? ](#8-What’s-RESTful)
- [x] [9. what is CORS? ](#9-what-is-CORS)
- [x] [10. How trace requests through services: Hệ thống của em có gọi qua nhiều thành phần, làm thế nào để giám sát thành phần này nhanh hay chậm?](#10-How-trace-requests-through-services-Hệ-thống-của-em-có-gọi-qua-nhiều-thành-phần-làm-thế-nào-để-giám-sát-thành-phần-này-nhanh-hay-chậm)
- [ ] [11. Design pattern: singleton, Factory, Facade](#11-Design-pattern-singleton-Factory-Facade)
- [ ] [12. microservices pattern: API Gateway, BFF](#12-microservices-pattern-API-Gateway-BFF)
- [x] [13. Chiến lược cache redis](#13-Chiến-lược-cache-redis)
- [ ] [14. What is Nginx?](#14-What-is-Nginx)
- [ ] [15. các cách deploy hệ thống ko downtime: blue/green, canary, …](#4-các-cách-deploy-hệ-thống-ko-downtime-bluegreen-canary-…)

- [V. Operating System](#Operating-System)
- [x] [1. Kernel space vs User space: tại sao tách biệt?](#1-Kernel-space-vs-User-space-tại-sao-tách-biệt)
- [x] [2. Signals: Cơ chế signal delivery trong kernel (e.g., SIGKILL vs SIGTERM)](#2-Signals-Cơ-chế-signal-delivery-trong-kernel-eg-SIGKILL-vs-SIGTERM)
- [x] [3. cgroups & namespaces: cách kernel isolation làm nền tảng cho Docker/K8s, làm sao docker chia sẻ ram với hệ điều hành chính](#3-cgroups-amp-namespaces-cách-kernel-isolation-làm-nền-tảng-cho-DockerK8s-làm-sao-docker-chia-sẻ-ram-với-hệ-điều-hành-chính)

- [VI. RBAC](#RBAC)
- [x] [1. Tại sao sử dụng RBAC mà ko phải user - permission](#1-Tại-sao-sử-dụng-RBAC-mà-ko-phải-user---permission)
- [x] [2. Các thành phần của JWT token](#2-Các-thành-phần-của-JWT-token)
- [x] [3. Thu hồi JWT](#3-Thu-hồi-JWT)
- [x] [4. Logout nhiều thiết bị](#4-Logout-nhiều-thiết-bị)
- [x] [5. Đổi mật khẩu](#5-Đổi-mật-khẩu)

- [VII. Design](#Design)
- [ ] [1. SOLID](#1-SOLID)

- [VIII. Community questions](#Community-questions)
- [ ] [1. So sánh mysql, postgres, oracle](#1-So-sánh-mysql-postgres-oracle)
- [x] [2. Vì sao chọn MongoDB mà không phải MySQL](#2-Vì-sao-chọn-MongoDB-mà-không-phải-MySQL)
- [x] [3. security trong microservices như nào](#3-security-trong-microservices-như-nào)
- [ ] [4. k đảm bảo thứ tự/ xử lí duy nhất kafka](#4-k-đảm-bảo-thứ-tự-xử-lí-duy-nhất-kafka)
- [x] [5. deadlock DB với mấy cơ chế lock optimistic lock/pesimistic lock cũng hay hỏi](#5-deadlock-DB-với-mấy-cơ-chế-lock-optimistic-lockpesimistic-lock-cũng-hay-hỏi)
- [x] [6. Python: list vs deque](#6-Python-list-vs-deque)
-----

https://chat.deepseek.com/a/chat/s/f15434dc-9615-4856-a804-135d30bfdf1d

# Database

## 1. How does SQL store and query data?

### How SQL Stores Data
SQL stores and queries data using a structured model based on tables, rows, and columns, and a query engine that translates declarative statements (SQL queries) into low-level storage operations.

- **Tables:** Data is organized into tables, each representing an entity (e.g., `Customers`, `Orders`).
- **Rows:** Each row (tuple) represents a record or instance of that entity.
- **Columns:** Each column (attribute) represents a property of the entity with a defined data type (e.g., `INT`, `VARCHAR`, `DATE`).
- **Indexes:** Special data structures (like B-trees or hash indexes) are maintained to speed up searches, joins, and filtering.

**Physical storage:**
- Most relational databases store data in pages/blocks (fixed-size chunks on disk).
- A table is stored as a collection of rows within these pages.
- Indexes map column values to the physical location of rows.

---

### How SQL Queries Data

- **Declarative Queries:** SQL queries describe *what* you want, not *how* to get it.
_Example:_

  SELECT name FROM Customers WHERE city='Paris';

- **Query Processor**
* **Parsing**: SQL text is parsed into a syntax tree.
* **Optimization**: The query planner decides the best strategy (use index scan vs. full table scan, join order, etc.).
* **Execution**: The engine retrieves the data using iterators or operators (e.g., scan, filter, join).
- **Execution strategies**:
* **Full table scan**: Reads every row if no index is usable.
* **Index scan**: Uses an index to jump directly to relevant rows.
* **Join algorithms**: Nested loops, hash joins, merge joins depending on query complexity and data size.

---

## 2. How index of MySQL is implemented?

In MySQL, indexes are implemented differently depending on the storage engine:

### 2.1. InnoDB (default engine)

- Uses a B+Tree structure for most indexes.
- The clustered (primary) index stores the actual table rows in the leaf nodes of the B+Tree. This means the table’s data is physically ordered by the primary key.
- Secondary indexes are also B+Trees, but their leaf nodes contain the indexed column(s) plus a pointer (the primary key value) to find the full row in the clustered index.
-> This design makes lookups by primary key very fast, but secondary index lookups require an extra step (first search in the secondary index, then use the primary key to fetch the row).

### 2.2. MyISAM

- Also uses B+Trees for indexes, but the leaves of the index tree store pointers to the physical row locations in the data file (not the primary key like in InnoDB).
- Unlike InnoDB, MyISAM indexes are not clustered—the data file is separate and not ordered by the index.

### 2.3. Other Index Types

- HASH indexes: Available in the MEMORY engine, implemented using hash tables, providing O(1) lookups but no ordering.
- FULLTEXT indexes: Use inverted index structures optimized for text searching.
- SPATIAL indexes: Implemented with R-Trees (mainly in MyISAM) for spatial (GIS) data.

👉 Summary:

- Most MySQL indexes are B+Trees.
- InnoDB’s clustered index = data is part of the index (organized by primary key).
- Secondary indexes in InnoDB point back to the clustered index via the primary key.
- MyISAM uses B+Trees too, but only stores pointers to rows in a separate data file.
- Special cases: HASH (for MEMORY), FULLTEXT, SPATIAL.

---
https://chatgpt.com/share/68a7d818-9ee0-8011-90a3-9e1b099f26ba

## 3. Difference and advantages of B+Tree comparing to BTree?
https://www.youtube.com/watch?v=JWSObwhGGxY&t=7s

---

## 4. How to install tree in database

(https://www.mongodb.com/docs/manual/applications/data-models-tree-structures/, https://www.baeldung.com/sql/storing-tree-in-rdb)

---

## 5. ACID in Database how the database make sure atomic feature?
(https://aistudio.google.com/prompts/1CrLsnMepiMb2qRVSPLa0hpmpwF1fpeWJ) trinhvanson1997

The core component that makes this possible is the **Transaction Log** (also known as a write-ahead log, journal, or redo/undo log).

### 5.1 The Technical Mechanism: Write-Ahead Logging (WAL)

The most common technique databases use to ensure atomicity is Write-Ahead Logging (WAL).
**Cardinal rule of WAL:**
A change must be written to the log on durable storage (like an SSD/HDD) before the change is written to the actual data files on durable storage.

#### Step-by-step: "Alice pays Bob" transaction using WAL

**Initial State:**
- Data File: Accounts Table → Alice: 5,000,000; Bob: 2,000,000
- Transaction Log: (empty for this transaction)

**Transaction Process:**
1. **BEGIN TRANSACTION;**
The database writes a `BEGIN TXN #123` record to the transaction log. This signals the start of a new atomic unit.

2. **UPDATE Accounts SET balance = 4000000 WHERE user_name = 'Alice';**
*WAL in action:* Before modifying the actual Accounts table on disk, the database writes a log entry with:
- Transaction ID: #123
- Table/Page modified: Accounts / Page 78
- Before Image: Alice's balance: 5,000,000
- After Image: Alice's balance: 4,000,000
This log entry is flushed to disk. Now, the intent to change is safely recorded. The database can now update the data in its in-memory copy (the buffer cache).

3. **UPDATE Accounts SET balance = 3000000 WHERE user_name = 'Bob';**
*WAL in action:* The same process happens again. A new log entry is written and flushed to disk first:
- Transaction ID: #123
- Table/Page modified: Accounts / Page 101
- Before Image: Bob's balance: 2,000,000
- After Image: Bob's balance: 3,000,000
The in-memory copy for Bob's account is updated.

4. **COMMIT;**
The database writes a final `COMMIT TXN #123` record to the transaction log and ensures it is flushed to disk.
This is the point of no return. As soon as this COMMIT record is safely on disk, the database considers the transaction complete and successful. It can now send a "success" message back to the application.
The actual changes to the main data files on disk might happen later at an optimal time. The log guarantees the change is permanent.

### 5.2 How WAL Handles Failures to Ensure Atomicity

#### Case 1: The System Crashes Before the COMMIT Record is Written

- Imagine the power goes out right after step 3. The `COMMIT TXN #123` record never made it to the log on disk.
- When the database restarts, it runs a recovery process:
- It reads the transaction log.
- It sees `BEGIN TXN #123` and the two UPDATE log entries.
- It scans forward but never finds a `COMMIT TXN #123` record.
- The database concludes that transaction #123 was not completed.
- It then performs a ROLLBACK. It uses the "Before Images" from the log entries to undo any changes that might have been partially written to the data files. It will restore Alice's balance to 5,000,000 and Bob's to 2,000,000.
- **Result:** "Nothing." The database is returned to its exact state before the transaction started. Atomicity is preserved.

#### Case 2: The System Crashes After the COMMIT Record is Written

- Imagine the power goes out a millisecond after the `COMMIT TXN #123` record is written to the log, but before the actual changes to Alice's and Bob's balances are written from memory to the main data files on disk.
- When the database restarts and runs recovery:
- It reads the transaction log.
- It sees the entire sequence for transaction #123, including the `COMMIT TXN #123` record.
- The database concludes that this transaction was successful and must be fully reflected in the data.
- It performs a ROLL FORWARD (also called redo). It uses the "After Images" from the log to re-apply the changes, ensuring Alice's balance is set to 4,000,000 and Bob's is set to 3,000,000 in the main data files.
- **Result:** "All." The transaction is fully and correctly completed, even though a crash occurred. Atomicity is preserved.

### 5.3 Summary

In short, the database ensures atomicity by:
- **Using a Transaction Log:** It records every intention to change data before the change is made permanent.
- **Following the Write-Ahead Logging (WAL) rule:** The log is the source of truth. The log entry must be on disk before the data it describes is changed on disk.
- **Using a Recovery Process:** Upon startup, it checks the log for incomplete (uncommitted) transactions to undo (Rollback) and for completed (committed) transactions to redo, guaranteeing the database state is always consistent and transactions are never left half-

---
## 6. Database Isolation(4 levels), what are they and what are the difference between them?

Hiểu rõ về 4 mức độ cô lập (Isolation Levels) là cực kỳ quan trọng vì nó thể hiện sự đánh đổi trực tiếp giữa tính nhất quán của dữ liệu (Consistency) và hiệu năng của hệ thống (Performance).

### 6.1 Các "Hiện Tượng" Cần Ngăn Chặn

Hãy tưởng tượng hai giao dịch đang chạy song song: T1 và T2.

#### Dirty Read (Đọc bẩn)
- **Tình huống:** T1 sửa đổi một dòng dữ liệu nhưng chưa COMMIT (cam kết). T2 đọc dòng dữ liệu đã được sửa đổi đó. Sau đó, T1 thực hiện ROLLBACK (hủy bỏ).
- **Hậu quả:** T2 đã đọc và có thể đã sử dụng một dữ liệu "bẩn", một dữ liệu chưa bao giờ tồn tại chính thức trong cơ sở dữ liệu.

#### Non-Repeatable Read (Đọc không lặp lại được)
- **Tình huống:** T1 đọc một dòng dữ liệu. Sau đó, T2 cập nhật hoặc xóa dòng dữ liệu đó và COMMIT. T1 đọc lại chính xác dòng dữ liệu đó một lần nữa và nhận được một giá trị khác (hoặc không tìm thấy).
- **Hậu quả:** Trong cùng một giao dịch, T1 thấy dữ liệu tự thay đổi, gây ra sự không nhất quán.

#### Phantom Read (Đọc bóng ma)
- **Tình huống:** T1 thực hiện một truy vấn lấy về một tập hợp các dòng dữ liệu theo một điều kiện nào đó (ví dụ: `SELECT * FROM products WHERE category = 'books'`). Sau đó, T2 chèn thêm một dòng dữ liệu mới (hoặc cập nhật một dòng cũ) cũng thỏa mãn điều kiện đó và COMMIT. T1 thực hiện lại chính xác câu truy vấn đó và thấy một "bóng ma" - một dòng dữ liệu mới xuất hiện mà không có ở lần đọc đầu tiên.
- **Hậu quả:** Tập hợp dữ liệu mà T1 đang làm việc bị thay đổi, có thể dẫn đến các
-
### 6.2 Bốn mức độ cô lập (4 Isolation Levels)

**Bối cảnh ví dụ:** Một bảng Products có hai sản phẩm:
id=101, name='Laptop', quantity=20
id=102, name='Mouse', quantity=50

#### 1. Read Uncommitted (Đọc dữ liệu chưa cam kết)
- Định nghĩa: Mức độ yếu nhất. Một giao dịch có thể thấy những thay đổi chưa được cam kết (uncommitted changes) của các giao dịch khác.
- Ngăn chặn: Không ngăn chặn được hiện tượng nào cả.
- Hiệu năng: Cao nhất, vì các giao dịch gần như không khóa (lock) lẫn nhau.

**Ví dụ (minh họa Dirty Read):**

| Thời gian | Giao dịch 1 (T1) | Giao dịch 2 (T2) - Báo cáo tồn kho |
|-----------|------------------|-------------------------------------|
| 1 | BEGIN; | |
| 2 | UPDATE Products SET quantity = 15 WHERE id = 101; (Trừ 5 cái Laptop) | |
| 3 | | BEGIN; |
| 4 | | SELECT quantity FROM Products WHERE id = 101; Đọc được giá trị là 15. |
| 5 | | Báo cáo ghi nhận tồn kho Laptop còn 15. |
| 6 | ROLLBACK; (Giao dịch bị lỗi, hủy bỏ) | |
| 7 | | COMMIT; |

> **Vấn đề:** Báo cáo của T2 nói rằng kho còn 15 Laptop, nhưng thực tế, vì T1 đã rollback nên số lượng Laptop vẫn là 20. Dữ liệu của T2 đã bị sai lệch hoàn toàn. Mức độ này rất hiếm khi được sử dụng trong thực tế.

---

#### 2. Read Committed (Đọc dữ liệu đã cam kết)
- Định nghĩa: Phổ biến nhất, là mức mặc định của hầu hết các cơ sở dữ liệu (PostgreSQL, SQL Server, Oracle). Một giao dịch chỉ có thể thấy những thay đổi đã được cam kết (committed changes) của các giao dịch khác.
- Ngăn chặn: Dirty Read.
- Hiệu năng: Cân bằng tốt giữa hiệu năng và tính nhất quán.

**Ví dụ (minh họa Non-Repeatable Read vẫn xảy ra):**

| Thời gian | Giao dịch 1 (T1) - Màn hình hiển thị giá | Giao dịch 2 (T2) - Admin cập nhật giá |
|-----------|------------------------------------------|---------------------------------------|
| 1 | BEGIN; | |
| 2 | SELECT quantity FROM Products WHERE id = 101; Đọc được 20. | |
| 3 | Hiển thị cho người dùng: "Tồn kho: 20" | BEGIN; |
| 4 | | UPDATE Products SET quantity = 10 WHERE id = 101; |
| 5 | | COMMIT; (Cập nhật thành công) |
| 6 | SELECT quantity FROM Products WHERE id = 101; Bây giờ đọc được 10. | |
| 7 | Người dùng làm mới và thấy "Tồn kho: 10" | |
| 8 | COMMIT; | |

> **Vấn đề:** Trong cùng một giao dịch T1, lần đọc đầu tiên và lần đọc thứ hai cho cùng một sản phẩm lại ra hai kết quả khác nhau (20 và 10). Dữ liệu đã "tự thay đổi". Điều này có thể chấp nhận được trong nhiều ứng dụng, nhưng sẽ là vấn đề nếu T1 đang thực hiện các tính toán phức tạp dựa trên lần đọc đầu tiên.

---

#### 3. Repeatable Read (Đọc lặp lại được)
- Định nghĩa: Mạnh hơn Read Committed. Đảm bảo rằng nếu một giao dịch đọc một dòng dữ liệu, nó sẽ luôn thấy cùng một dữ liệu cho dòng đó trong suốt thời gian giao dịch. Nó thực hiện điều này bằng cách giữ các khóa đọc (read locks) trên tất cả các dòng mà nó đã đọc.
- Ngăn chặn: Dirty Read, Non-Repeatable Read.
- Hiệu năng: Thấp hơn Read Committed do tăng cường khóa. Mặc định của MySQL (InnoDB).

**Ví dụ (minh họa Phantom Read vẫn xảy ra):**

| Thời gian | Giao dịch 1 (T1) - Đếm sản phẩm trong kho | Giao dịch 2 (T2) - Nhập hàng mới |
|-----------|-------------------------------------------|----------------------------------|
| 1 | BEGIN; | |
| 2 | SELECT COUNT(*) FROM Products WHERE quantity > 10; Đếm được 2 sản phẩm. | |
| 3 | | BEGIN; |
| 4 | | INSERT INTO Products VALUES (103, 'Keyboard', 30); |
| 5 | | COMMIT; (Nhập hàng mới thành công) |
| 6 | SELECT COUNT(*) FROM Products WHERE quantity > 10; Bây giờ đếm được 3 sản phẩm! | |
| 7 | Báo cáo của T1 không nhất quán. | |
| 8 | COMMIT; | |

> **Vấn đề:** T1 đã ngăn được việc các dòng hiện có bị thay đổi (Non-Repeatable Read), nhưng nó không thể ngăn các dòng mới được chèn vào. Dòng sản phẩm Keyboard mới này giống như một "bóng ma" xuất hiện trong lần đọc thứ hai, làm thay đổi kết quả của T1.

---

#### 4. Serializable (Tuần tự hóa)
- Định nghĩa: Mức độ mạnh nhất, an toàn nhất. Nó đảm bảo rằng kết quả của các giao dịch đồng thời sẽ giống hệt như khi chúng được thực thi một cách tuần tự (nối tiếp nhau). Nó thực hiện điều này bằng các kỹ thuật khóa rất chặt chẽ, có thể là khóa cả một khoảng (range locks) hoặc cả bảng.
- Ngăn chặn: Dirty Read, Non-Repeatable Read, Phantom Read.
- Hiệu năng: Thấp nhất, vì nó làm giảm đáng kể khả năng chạy song song của các giao dịch.

**Ví dụ (giải quyết Phantom Read):**

| Thời gian | Giao dịch 1 (T1) - Đếm sản phẩm trong kho | Giao dịch 2 (T2) - Nhập hàng mới |
|-----------|-------------------------------------------|----------------------------------|
| 1 | BEGIN; | |
| 2 | SELECT COUNT(*) FROM Products WHERE quantity > 10; Đếm được 2 sản phẩm. | |
| 3 | | BEGIN; |
| 4 | | INSERT INTO Products VALUES (103, 'Keyboard', 30); Giao dịch này bị BLOCK (khóa) và phải chờ. |
| 5 | SELECT COUNT(*) FROM Products WHERE quantity > 10; Vẫn đếm được 2 sản phẩm. | |
| 6 | COMMIT; (T1 kết thúc) | |
| 7 | | Giao dịch T2 bây giờ mới được tiếp tục và thực hiện INSERT. |

> **Giải quyết:** T2 không thể chèn dữ liệu mới vào tập hợp mà T1 đang làm việc cho đến khi T1 kết thúc. Điều này đảm bảo rằng T1 có một "snapshot" hoàn toàn tĩnh của dữ liệu trong suốt thời gian tồn tại của nó, loại bỏ hoàn toàn hiện tượng

#### Bảng Tóm Tắt
| | Dirty Read | Non-Repeatable Read | Phantom Read |
|-------------------------|------------|---------------------|--------------|
| **Read Uncommitted** | Cho phép | Cho phép | Cho phép |
| **Read Committed** | Ngăn chặn | Cho phép | Cho phép |
| **Repeatable Read** | Ngăn chặn | Ngăn chặn | Cho phép |
| **Serializable** | Ngăn chặn | Ngăn chặn | Ngăn chặn |

### 6.3 Kết luận
**Read Committed** là lựa chọn **phổ biến nhất** vì nó mang lại sự cân bằng hợp lý giữa việc bảo vệ dữ liệu và duy trì hiệu năng tốt. Các mức độ cao hơn như **Repeatable Read hoặc Serializable** chỉ nên được sử dụng khi **nghiệp vụ yêu cầu tính nhất quán dữ liệu tuyệt đối**, ví dụ như trong các hệ thống xử lý **giao dịch tài chính**

----

## 7. Index types in database (tips javascipt), when to use it
mysql: https://youtu.be/UYmCFPVx-XY?t=131
mongo: https://youtu.be/fPMDkPrRiYo?t=1148

- MySQL:
- Normal Index
- Unique Index
- Primary Key Index
- Fulltext Index : Tìm kiếm theo startsWith
- Composite Index : đánh index theo nhiều trường
- MongoDB:
- Single Field Index: Đánh chỉ mục 1 trường
- Compound Index: Đánh chỉ mục nhiều trường
- Unique Index
- Hash Index

Một số lưu ý để tối ưu hiệu năng:
- Không bắt DB tính toán hết mọi thứ -> cái gì dùng backend tính được thì để ở backend
- Không query prefix, regex, text trên collection lớn -> dùng search engine riêng luôn (Elasticsearch)
- Caching các data ít thay đổi

Composite Index: Index trên nhiều cột.
---
## 8. Advantages and disadvantages of DB Indexing?
https://chat.deepseek.com/a/chat/s/31bdc459-f5f9-4233-98ff-c7b1a7883c99
https://www.datacamp.com/doc/mysql/mysql-b-tree

- Ưu điểm:
- Tốc độ truy vấn nhanh hơn: Giảm đáng kể thời gian cho các câu lệnh SELECT, WHERE, JOIN và ORDER BY.
- B-TREE indexes tối ưu cho truy vấn theo khoảng (range ngày tháng hoặc sắp xếp). Trong khi đó, HASH indexes phù hợp cho so sánh ngang bằng (equal)
- Nhược điểm:
- Làm chậm thao tác ghi: Các lệnh INSERT, UPDATE, DELETE chậm hơn do phải cập nhật cả index.
- Tốn thêm dung lượng: Index chiếm thêm không gian đĩa.

---

## 9. n+1 problems

---

## 10. Đã dùng NoSQL bao giờ chưa, điểm mạnh của NoSQL hơn so với RDBMS là gì? RDBMS có thể scale được không? Có thể có nhiều master cho RDBMS không?

---

## 11. Tại sao các ngân hàng và hệ thống lớn thường sử dụng Oracle thay vì SQL Server?

https://www.youtube.com/watch?v=TvLWozM182E

### 1. Cơ chế xử lý giao dịch đồng thời
- Tình huống:
+ A và B dùng chung tài khoản ngân hàng, số dư: 1000$
+ A thực hiện rút 100$ từ tài khoản (UPDATE), nhưng chưa xác nhận (COMMIT)
+ Cùng lúc đó, B vào xem số dư tài khoản (SELECT)
- Hỏi: B nhìn thấy số dư là bao nhiêu, 1000$ hay 900$?
- Trả lời:
Với cơ chế mặc định của oracle và sql server
+ Oracle: B vẫn nhìn thấy số dư là 1000$
+ SQL Server: Câu lệnh SELECT của B bị treo cho đến khi A xác nhận COMMIT giao dịch -> nếu có hàng ngàn giao dịch xảy ra -> hệ thống chậm.
Để giải quyết vấn đề bị treo của SQL Server, cần phải thay đổi cấu hình khi cài đặt (nguyên tắc xử lý bên dưới: tạo thêm 1 chỗ lưu mới, một chỗ chỉ dành cho SELECT) -> SQL Server không phải chờ nữa mà trả về 1000$. Tuy nhiên, đến năm 2005 mới có tính năng này trong khi oracle có trước
=> +1 lý do chọn Oracle

### 2. Hiện tượng leo thang lock (Lock escalation) - Rất quan trọng trong các hệ thống ngân hàng
- Tình huống:
+ A và B dùng chung tài khoản ngân hàng, số dư: 1000$
+ A thực hiện rút 100$ từ tài khoản (UPDATE), nhưng chưa xác nhận (COMMIT)
+ Cùng lúc đó, B thực hiện rút 500$
- Hỏi: B có rút được không?
- Trả lời:
Một số loại cơ sở dữ liệu (như SQL Server) sẽ khóa toàn bộ bảng khi có một giao dịch UPDATE xảy ra, dẫn đến việc B không thể rút tiền vì bảng đã bị khóa.
Trong khi đó, Oracle chỉ khóa các hàng cụ thể liên quan đến giao dịch của A, cho phép B vẫn có thể rút tiền nếu số dư đủ.
=> +1 lý do chọn Oracle

Chiến lược thực thi câu lệnh (Execution Plan)

### 3. Kỹ thuật Partition khi lưu trữ dữ liệu lớn
Ví dụ: Tìm kiếm dữ liệu giao dịch trong một tháng gần nhất trong bảng transactions với hàng triệu bản ghi

SELECT * FROM transactions WHERE transaction_date >= '2025-01-01' AND transaction_date < '2025-01-15';

Thay vì quét toàn bộ bảng. Sử dụng pảtition để chia dữ liệu bảng theo tháng (01/2025,02/2025,...), dựa vào ngày giao dịch trong câu query để xác định partition cần quét -> cải thiện hiệu suất truy vấn.

Ví dụ 2: Tìm kiếm dữ liệu giao dịch trong một tháng gần nhất và theo địa điểm giao dịch

SELECT * FROM transactions WHERE transaction_date >= '2025-01-01' AND transaction_date < '2025-01-15' AND location = 'Hanoi';

| Partition (Tháng) | Sub Partition (Địa điểm) | Dữ liệu chứa |
|-------------------|--------------------------|-----------------------------------------------|
| 01/2025 | Hà Nội | Giao dịch tại Hà Nội trong tháng 01/2025 |
| 01/2025 | TP.HCM | Giao dịch tại TP.HCM trong tháng 01/2025 |
| 01/2025 | Đà Nẵng | Giao dịch tại Đà Nẵng trong tháng 01/2025 |
| 02/2025 | Hà Nội | Giao dịch tại Hà Nội trong tháng 02/2025 |
| 02/2025 | TP.HCM | Giao dịch tại TP.HCM trong tháng 02/2025 |
| 02/2025 | Đà Nẵng | Giao dịch tại Đà Nẵng trong tháng 02/2025 |
| ... | ... | ... |

- **Oracle** hỗ trợ sub partition, cho phép chia nhỏ dữ liệu hơn nữa, ví dụ: chia theo tháng và chia theo địa điểm giao dịch.
- **SQL Server** hỗ trợ partition, nhưng chỉ cho phép chia theo một tiêu chí duy nhất (ví dụ: theo tháng).
=> +1 lý do chọn Oracle

### 4. Indexing
Bitmap Index:
- **Oracle** hỗ trợ bitmap index, cho phép tối ưu hóa truy vấn trên các cột trường có giá trị lặp lại nhiều lần (ví dụ: giới tính, trạng thái đơn hàng).
- **SQL Server** không hỗ trợ bitmap index, chỉ có thể sử dụng các loại index khác như B-tree index.

### 5. Parallel
- **Oracle**: hỗ trợ chạy song song nhiều core cpu cho tất cả loại truy vấn CRUD
- **SQL Server**: chỉ hỗ trợ chạy song song với câu lệnh SELECT

### 6. Flashback
- **Oracle** cho phép khôi phục dữ liệu trong một khoảng thời gian trước đó bằng cách đọc từ **undo**

### 7. Tính ổn định

---
## 12. Quá trình thực hiện một câu query
- **Parsing and Lexical Analysis:** parses this string and verifying its syntax against the SQL grammar
- **Semantic Analysis:** performs semantic analysis to ensure the query is logically sound. This involves checking if tables and columns referenced in the query exist
- **Query Optimization:** This is a crucial stage where the DBMS determines the most efficient way to execute the query. The optimizer considers various execution plans, such as using indexes, joining tables in different orders, or performing full table scans. It estimates the cost of each plan and selects the one with the lowest estimated cost
- **Execution:** execute selected plan and return result

---
## 13. Các bước tối ưu performance (xem lại)
1. Sử dụng EXPLAIN để phân tích execution plan.
2. Thêm Index phù hợp cho các cột trong WHERE, JOIN, ORDER BY.
3. Tối ưu hóa câu query: Tránh SELECT *, tránh subquery không cần thiết, sử dụng LIMIT.
4. Thiết kế schema hợp lý (normalization/denormalization).
5. Điều chỉnh cấu hình database (buffer sizes, cache settings).
6. Scale hệ thống (read replicas, sharding).

---
## 14. CAP theorem?

## 15. Các dạng chuẩn (Normalization)
https://datapot.vn/chuan-hoa-du-lieu-la-gi-1nf-2nf-3nf-datapot/?srsltid=AfmBOopZtUXAasAE9rhmAd1cAiWYJ4i7g0GBD2Jey1sGYp-yQfAvK_cp

---
# Security

## 1. Thuật toán mã hóa AES và RSA

### 1.1 AES (Advanced Encryption Standard) - Mã hóa đối xứng
- Chỉ sử dụng **một khóa duy nhất** cho cả quá trình mã hóa (biến dữ liệu thành dạng không đọc được) và giải mã (biến ngược lại thành dữ liệu gốc).
- **Ưu điểm**: **Rất nhanh, lý tưởng để mã hóa các tệp lớn**, cơ sở dữ liệu, hoặc luồng dữ liệu liên tục.
- **Nhược điểm**: **Làm thế nào để chia sẻ khóa bí mật một cách an toàn** (ví dụ giữa web client và server). Nếu khóa bị lộ trong lúc truyền đi, toàn bộ dữ liệu sẽ bị xâm phạm

### 1.2 RSA (Rivest-Shamir-Adleman) - Mã hóa bất đối xứng
- Sử dụng **một cặp khóa** có quan hệ toán học với nhau: một khóa công khai (Public Key) và một khóa riêng tư (Private Key).
- **Khóa công khai**: **Có thể chia sẻ** cho bất kỳ ai. **Dùng để mã hóa** dữ liệu.
- **Khóa riêng tư**: Phải được giữ **bí mật tuyệt đối**. **Dùng để giải mã** dữ liệu tương ứng.
- **Ưu điểm**: **Giải quyết triệt để vấn đề chia sẻ khóa an toàn của AES**.
- **Nhược điểm**: **tốc độ chậm hơn AES rất nhiều**.

### 1.3 Kết luận
- Trong thực tế, **AES và RSA thường được sử dụng cùng nhau** để tận dụng thế mạnh của cả hai, tạo nên một hệ thống bảo mật cực kỳ hiệu quả.
- Đầu tiên sử dụng RSA để chia sẻ khóa chung, sau đó sử dụng AES để mã hóa thông tin. Ví dụ: TLS trong HTTPS

## 2. SSL/TLS/HTTPS?
https://www.youtube.com/watch?v=j9QmMEWmcfo

Key note: TLS is a handshake process between the client and server with asymmetric encryption to exchange a session key used for Data Transmission with symmetric encryption.

### 2.1 HTTPS (Hypertext Transfer Protocol Secure)
HTTPS = HTTP + TLS (Transport Layer Security)

* **Định nghĩa**: HTTPS là một **phiên bản mở rộng của giao thức HTTP**
* **Mục đích**: Cung cấp **bảo mật** cho việc truyền dữ liệu qua Internet
* **Cơ chế bảo mật**: HTTPS sử dụng **TLS để mã hóa dữ liệu**

### 2.2 TLS (Transport Layer Security)

* **Định nghĩa**: TLS là **giao thức bảo mật** mà HTTPS sử dụng để mã hóa dữ liệu
* **Quá trình thiết lập kết nối an toàn (TLS Handshake)**:
* **Bước 1**: Trình duyệt thiết lập một **kết nối TCP** với máy chủ
* **Bước 2 (Giai đoạn Hello)**:
* Trình duyệt gửi `client hello` để cho máy chủ biết phiên bản TLS và bộ mã hóa (cipher suite) mà nó hỗ trợ
* Máy chủ phản hồi bằng `server hello`, chọn phiên bản TLS và bộ mã hóa để sử dụng, sau đó **server tạo cặp khóa bất đối xứng**, gửi **khóa công khai (RSA)** cho client
* **Bước 3 (Trao đổi khóa)**:
* Client tạo ra **session key (khóa đối xứng AES)**, mã hóa nó bằng **khóa công khai (RSA)** và gửi đến server
* Server nhận và giải mã session key bằng khóa riêng của mình. **Nhờ đó, session key được trao đổi an toàn qua Internet**
* **Bước 4 (Truyền dữ liệu)**: Sau khi cả hai bên có session key, họ sẽ sử dụng khóa này và bộ mã hóa đã thống nhất để **gửi dữ liệu đã mã hóa** qua lại trong một kênh an toàn bằng **mã hóa đối xứng**
* **Lý do kết hợp mã hóa bất đối xứng và đối xứng**: Mã hóa bất đối xứng **tốn kém về mặt tính toán** (computationally expensive) nên không phù hợp cho việc truyền dữ liệu khối lượng lớn. Mã hóa đối xứng hiệu quả hơn cho việc truyền dữ liệu thực tế
* **Phiên bản TLS**:
* **TLS 1.2**: Quá trình handshake yêu cầu **hai lần trao đổi qua lại trên mạng** Sử dụng RSA hoặc Diffie-Hellman cho việc trao đổi khóa phiên
* **TLS 1.3**: Là phiên bản mới nhất, tối ưu hóa quá trình handshake để giảm số lần trao đổi qua lại trên mạng xuống **chỉ còn một lần**. TLS 1.3 **không còn hỗ trợ RSA** làm phương pháp trao đổi khóa, mà **Diffie-Hellman** là cách phổ biến hơn hiện nay

---
## 3. What happens when you type URL into your browser?
https://www.youtube.com/watch?v=AlkDbnbv7dk

1. Get domain from URL
- URL structure: scheme://domain/path
eg. https://example.com/a/b -> domain is **example.com**
2. Browser looks up IP in **DNS Cache**
2.1 If not found, continue looks up in DNS Resolver and DNS Server
-> Know IP address of server
3. Establish connection with server via TCP
4. Send request
5. Recieve response and render page

---
# Network
## 1. HTTP/TCP/UDP

---
## 2. So sánh HTTP 1, 1.1, 2 và 3
https://www.youtube.com/watch?v=a-sBfyiXysI&t=1s
https://www.baeldung.com/cs/http-versions#3-http-version-20

**Http/1/1.1/2 are built on TCP**

**Http 1.0:** open connection for each request

**Http/1.1:**
- **Persistent connections**: introduces **"keep-alive"** which allows a connection to reuse and avoid the expensive 3 way handshake

**Http/2:**
- **multiplexing**: HTTP 1.1 is a sequential protocol. So, we can send a single request at a time. HTTP 2.0 allows to send requests and receive responses asynchronously. In this way, we can do multiple requests at the same time using a single connection
- **compression**: executes a GZip compression automatically
- **server push**

**Http/3:**
- introduces **QUIC protocol based on UDP** to make stream first class in transportation layer, replacing TCP usage for mobile devices, reduce lag when change from wifi to other network

---
## 3. So sánh websocket và HTTP, websocket xài giao thức nào

---
## 4. OSI 7 layers

---
# Programming

## 1. Process vs Thread
https://www.youtube.com/watch?v=4rLW7zg21gI
1. **Program**
A program is a **set of instructions written in a specific programming language** that the computer can execute. It is essentially a blueprint, and it does not perform any action until it is run.

2. **Process**
- A process is **an instance of a program in execution**. When a program is loaded into memory (RAM) and executed by processor (CPU), it becomes a process. A process has its own memory space, system resources, and an operating system environment.
- **Example**: When you open a web browser (like Chrome or Firefox), a process is created for it. Each tab within the browser might even have its own process, depending on the browser design.

3. **Thread**
- A thread is **the smallest unit of execution within a process**. A process can have multiple threads, all sharing the same memory but running independently. Threads within a process can perform different tasks simultaneously, improving efficiency.
- Example: In your web browser, multiple threads might handle different tasks: one for rendering the page, another for handling user input, and yet another for network requests. These threads all work within the same browser process.

---

## 2. Concurrency vs Parallelism: Are they the same or different?

---
## 3. LinkedList vs. ArrayList (Java implement)
* **ArrayList**: Được build dựa trên static array, sử dụng một vùng nhớ liền nhau trên RAM. Ưu điểm truy cập ngẫu nhiên nhanh O(1) (getIndex(i) = firstArray + i * sizeOfMem). Chèn/xóa ở giữa chậm O(n) (vì phải dịch chuyển phần tử). Trường hợp, đầy capacity -> tạo static array gấp đôi array cũ và move các phần tử sang array mới.

* **LinkedList**: Dựa trên danh sách liên kết. Sử dụng các ô nhớ ko cần liên tiếp nhau, giúp linh hoạt trong việc cấp phát bộ nhớ tuy nhiên phải lưu thêm con trỏ đến node kế tiếp. Chèn/xóa ở bất kỳ đâu nhanh O(1) nếu đã có con trỏ. Truy cập ngẫu nhiên chậm O(n) (vì phải duyệt từ đầu).

---
## 4. How HashMap is implemented? (Java implement)

**Mảng + Danh sách liên kết/Cây**
* Dữ liệu được lưu trong một mảng các buckets (mặc định: 16 buckets)
* Khi chèn một cặp key-value, hashCode() của key được tính toán để xác định bucket cần lưu.
* Nếu nhiều key khác nhau cùng rơi vào một bucket (hash collision), chúng được lưu thành một danh sách liên kết.
* Khi số phần tử trong một bucket vượt quá ngưỡng (TREEIFY_THRESHOLD, thường là 8), danh sách liên kết **trong bucket đó** được chuyển thành cây đỏ-đen (Red-Black Tree) để tăng **tốc độ tìm kiếm từ O(n) lên O(log n)**.
* Khi số phần tử trong cây giảm xuống dưới ngưỡng (UNTREEIFY_THRESHOLD, thường là 6), nó được chuyển lại thành danh sách liên kết.

---
## 5. How do computers understand your code?

---
## 6. Chiến lược cache, invalidate cache
https://chat.deepseek.com/a/chat/s/e5fa01f2-38e2-4963-8daa-98db03528bf8

* Chiến lược ghi cache:
* Cache-aside: App kiểm tra cache trước, nếu không có thì lấy từ DB và cập nhật cache. Phổ biến nhất.
* Write-through: Ghi dữ liệu vào cache và DB đồng thời.
* Write-behind: Ghi vào cache trước, sau đó ghi bất đồng bộ vào DB.
* Invalidate cache (vô hiệu hóa):
* TTL (Time-To-Live): Dữ liệu tự động hết hạn.
* Explicit Invalidation: Chủ động xóa cache khi dữ liệu trong DB thay đổi (ví dụ: sau khi UPDATE).

---

## 7. race condition

---
## 8. What’s RESTful?
- Là một tiêu chuẩn thiết kế web api được một tổ chức đưa ra và cộng động công nhận, sử dụng rộng dãi

---
## 9. what is CORS?
https://www.explainthis.io/en/swe/what-is-cors

---
## 10. How trace requests through services: Hệ thống của em có gọi qua nhiều thành phần, làm thế nào để giám sát thành phần này nhanh hay chậm?
- Thu thập trace span bằng OpenTelemetry kết hợp với Jaeger để hiển thị luồng gửi giữa các service, cuối cùng xuất metrics vào Prometheus và hiển thị dashboard trên grafana, set alert khi request chậm gửi thông báo đến dev

## 11. Design pattern: singleton, Factory, Facade
---
## 12. microservices pattern: API Gateway, BFF
---
## 13. Chiến lược cache redis

## 14. What is Nginx?

- Nginx is a web server, solves thousands of concurrent connection.
- It can act as a reverse proxy, load balancer, and HTTP cache all at once
- Nginx as a Reverse Proxy: hides internal server structure from potential attackers, handles SSL encryption in one place and can route different types of requests to specialized servers
- Load balancer: handle much higher traffic volumes, provides better reliability (if one server fails, others continue serving requests)
- Cache: reduce response time for static contents

## 15. các cách deploy hệ thống ko downtime: blue/green, canary, ...

---
# Operating System

## 1. Kernel space vs User space: tại sao tách biệt?
https://notes.kodekloud.com/docs/Certified-Kubernetes-Security-Specialist-CKS/System-Hardening/Linux-Syscalls

### 1.1 What is kernel?
The Linux kernel is the central component that acts as **an interface between the hardware and running processes**. It efficiently manages system resources by operating in a dedicated memory area called kernel space, while user applications (written in languages such as C, Java, or Python) run in user space. The **kernel space contains the kernel code, device drivers, and its extensions—all essential for proper communication between hardware and applications**.

### 1.2 How program uses system call?

- System calls **enable applications running in user space to request services from the kernel**. For instance, when an application needs to open a file stored on disk, it cannot access the hardware directly; instead, it must instruct the kernel to perform the necessary operations
- One effective method for **tracing the system calls made by a process** is by using the ***strace*** command

### 1.3 Tại sao cần tách biệt kernel space và user space?
- **Bảo vệ hệ thống tăng tính ổn định**: Ngăn chặn một ứng dụng bị lỗi (chạy trong User space) làm sập toàn bộ hệ điều hành. Nếu một chương trình crash, chỉ mình nó bị ảnh hưởng, Kernel và các chương trình khác vẫn an toàn.
- **Tăng cường Bảo mật**: Không cho phép ứng dụng truy cập trực tiếp vào tài nguyên phần cứng quan trọng (bộ nhớ, CPU, ổ cứng). Buộc mọi yêu cầu đặc quyền phải thông qua Kernel để kiểm tra và phê duyệt, giúp chống lại mã độc và các hành vi truy cập trái phép.
- **Cơ chế giao tiếp có kiểm soát**: Hai không gian này giao tiếp với nhau thông qua một cổng duy nhất gọi là System Calls. Kernel sẽ nhận yêu cầu từ ứng dụng, xác thực và thực thi một cách an toàn.

---
## 2. Signals: Cơ chế signal delivery trong kernel (e.g., SIGKILL vs SIGTERM)
https://kdata.vn/tin-tuc/su-khac-nhau-giua-2-tin-hieu-sigterm-va-sigkill-trong-linux
### 2.1 SIGTERM
Tín hiệu **SIGTERM được sử dụng để yêu cầu chấm dứt (terminate) hoạt động của một tiến trình** (process). Một tiến trình nhận Sigterm sẽ có 3 trạng thái dễ thấy:
- Không phản ứng gì cả: ứng dụng KHÔNG được lập trình để xử lý sigterm
- Dừng ngay lập tức
- Một thời gian ngắn sau sẽ dừng hoạt động. Trong thời gian đó tiến trình sẽ dọn dẹp các resource như database connection, tiến trình con,… (graceful shutdown).

> # command
> kill -15 <process_id>

### 2.2 SIGKILL
- SIGKILL được sử dụng để chấm dứt quá trình hoạt động của một tiến trình ngay lập tức. Tín hiệu này không thể bị từ chối hay bị ngăn cản bởi tiến trình được chỉ định
- Tuy nhiên, không phải lúc nào kernel cũng có thể dừng quá trình hoạt động của tiến trình thành công trong vài tình huống. Ví dụ như tiến trình đang chờ đợi disk io, network,… từ đó kernel không có khả năng dừng tiến trình được. Khi đấy sẽ sinh ra các Zombie process ở trạng thái uninterruptible sleep.

> # command
> kill -9 <process_id>

### 2.3 So sánh sự khác nhau
- Sigterm yêu cầu tiến trình dừng hoạt động. Còn Sigkill thì chấm dứt hoạt động của tiến trình ngay lập tức.
- Sigterm có thể được xử lý hoặc từ chối xử lý quá trình dừng hoạt động bởi tiến trình. Còn Sigkill thì không tiến trình có cơ hội ngăn chặn hay từ chối cả.
- Sigterm sẽ không dừng hoạt động của tiến trình con. Còn Sigkill sẽ dừng hoạt động cả tiến trình cha và tiến trình con nếu có.
- Sigkill dễ tạo ra các tiến trình ma (zombie process) vì tiến trình bị ngừng hoạt động sẽ không có cơ hội thông báo cho tiến trình cha hoặc tiến trình con về việc bị ngừng hoạt động.
=> Thông thường cách dừng hoạt động một tiến trình đúng đắn nên là dùng Sigterm trước. Trừ khi tiến trình đó không phản hồi, hoặc không xử lý Sigterm thì kill bằng Sigkill.

---
## 3. cgroups & namespaces: cách kernel isolation làm nền tảng cho Docker/K8s, làm sao docker chia sẻ ram với hệ điều hành chính
- Container là một công nghệ mà cho phép chúng ta chạy một chương trình trong một môi trường độc lập hoàn toàn với các chương trình còn lại trên cùng một máy tính
- **Linux Namespaces** ( cho phép ta tạo ra một virtualize system, khá giống với chức năng của các công cụ virtual machine) gồm các thành phần:
+ **PID namespace:** cho phép ta tạo các process tách biệt.
+ **Networking namespace:** cho phép ta chạy chương trình trên bất kì port nào mà không bị xung độ với các process khác chạy trên server.
+ **Mount namespace:** cho phép ta mount và unmount filesystem mà không ảnh hưởng gì tới host filesystem.
- **Cgroups** (định ra giới hạn của CPU và Memory mà một process có thể dùng):
=> container là một sự kết hợp của hai tính năng cgroups và namespace

Docker chỉ là một công cụ giúp ta tương tác với công nghệ container ở bên dưới, chứ nó không phải là container. Nói chính xác hơn docker là một tool giúp ta tương tác với container một cách dễ dàng thay vì ta phải làm nhiều thứ

tham khảo:
- https://tuyendung.evotek.vn/hieu-don-gian-ve-namespaces-cgroups-va-unionfs-trong-docker-roadmap/
- https://viblo.asia/p/container-story-linux-namespaces-and-cgroups-what-are-containers-made-from-gDVK2r7jKLj

---
# RBAC

## 1. Tại sao sử dụng RBAC mà ko phải user - permission

(https://www.youtube.com/watch?v=iE9Qb8dHqWI)

---
## 2. Các thành phần của JWT token
- **Header**
- Contains metadata about the token itself
- Typically consists of two parts:
- **typ**: The type of token, which is "JWT"
- **alg**: The signing algorithm used (e.g HS256)
- **Payload**
- Contains the "claims" – the **statements about the user and any additional data**
- Example: { "sub": "1234567890", "name": "John Doe", "admin": true, "iat": 1516239022 }
- **Important**: The payload is encoded, not encrypted. Anyone can decode it and read its contents. Therefore, you should never store sensitive information (like passwords) in a JWT payload
- **Signature**
- It is created by combining the encoded header and payload with a secret key using the algorithm specified in the header
- **signature = HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)**

**Chú ý:** JWT thường được lưu ở cookie (tự động gửi kèm request) hoặc localStorage

---
## 3. Thu hồi JWT
https://www.youtube.com/watch?v=z84fkObC5Pw&t=230s
thêm userId vào blacklist

---
## 4. Logout nhiều thiết bị: logout 1 thiết bị ko ảnh hưởng đến thiết bị khác
https://www.youtube.com/watch?v=IEEdKxXk3SQ&t=264s
- Thêm một thuộc tính vào payload để phân biệt thiết bị

# khi logout
redis.set("TOKEN_BLACKLIST_{uid}_{jit}", 1)

ví dụ: Thêm jit dạng uuid

{
  "uid": "1234567890",                               # user id
  "name": "John Doe",                                # name
  "jit" : "269b8664-1695-416a-8c80-b38587d7bede",    # just in time
  "iat": 1516239022                                  # issuedAt
}

---
## 5. Đổi mật khẩu
https://www.youtube.com/watch?v=IEEdKxXk3SQ&t=264s
thêm timestamp để xác định thời gian đổi mật khẩu (changePasswordTime), vô hiệu hóa các token có thời gian tạo (issuedAt) trước changePasswordTime

# khi đổi mật khẩu
redis.set("TOKEN_IAT_AVAILABLE_{uid}, changePasswordTime)

# luồng xác thực khi đổi mật khẩu
decoded = jwt.verify(token, JWT_SECRET)
changePasswordTime = redis.get("TOKEN_IAT_AVAILABLE_{decoded.uid}") 

# nếu có key này -> đã có sự kiện đổi mật khẩu
if (changePasswordTime && (decoded.iat < changePasswordTime)){
    return "Token invalidated due to password changed"
}

---
## 6. RBAC vs ABAC

---
# Design
## 1. SOLID

---
# Community questions

## Anh em có câu hỏi nào mà thấy thường bị hỏi thì để ở đây nhé

## 1. So sánh mysql, postgres, oracle
https://www.youtube.com/watch?v=MV8moKp1Wxw

---
## 2. Vì sao chọn MongoDB mà không phải MySQL
https://www.youtube.com/watch?v=tnUBjJJnwn0
Những tiêu chí nên chọn MongoDB, tick vào ô chỉ ra tiêu chí ứng với dự án bạn đang làm
- [x] Ít dùng transaction
- [x] Thường xuyên thay đổi model
- [ ] QPS cao 2000-3000 qps / giây
- [ ] Dữ liệu mỗi ngày nhiều như IoT
- [x] Team ít người, dự án cần phát triển nhanh
- [x] Tính sẵn sàng mở rộng dọc ngang
- [ ] Location query
- [ ] Nested model

---
## 3. security trong microservices như nào
- Xác thực, phân quyền tập trung sử dụng API Gateway làm đầu vào duy nhất của hệ thống
- áp dụng nguyên tắc least privileges
- mã hóa giao tiếp nội bộ bằng mTLS (ví dụ: istio)
- Quản lý secrets một cách an toàn: k8s secret, vault

---
## 4. k đảm bảo thứ tự/ xử lí duy nhất kafka

---
## 5. deadlock DB với mấy cơ chế lock optimistic lock/pesimistic lock cũng hay hỏi
https://www.youtube.com/results?search_query=optimistic+lock+and+pessimistic+lock+

## 5.1 Pessimistic Lock (Khóa bi quan)
- Coi xung đột khi giao dịch đồng thời thường xuyên xảy ra
- Cơ chế: Khi một transaction đọc dữ liệu để cập nhật, nó sẽ khóa (lock) bản ghi đó lại. Các transaction khác muốn đọc/ghi vào bản ghi này phải chờ cho đến khi lock được giải phóng
- Ưu điểm: Đảm bảo tuyệt đối không xảy ra race condition.
- Nhược điểm: Hiệu suất thấp nếu có quá nhiều transaction phải chờ nhau, dễ dẫn đến tắc nghẽn

## 5.2 Optimistic Lock (Khóa lạc quan)
- Coi xung đột khi giao dịch đồng thời ít khi xảy ra
- Cơ chế: Thay vì khóa bản ghi, ta thêm một phiên bản (cột version) cho bản ghi. Mỗi lần cập nhật, ta kiểm tra xem phiên bản có còn giống lúc đọc hay không
- Ưu điểm: Hiệu suất cao, không có lock, phù hợp với các hệ thống có tần suất cập nhật không quá cao.
- Nhược điểm: Ứng dụng phải xử lý trường hợp cập nhật thất bại và thử lại hoặc thông báo lỗi.

## 6. Python: list vs deque

Here’s your content reformatted into clean **Markdown**:

---

### Performance Comparison

| Operation | List | Deque |
| ------------- | ---- | ----- |
| Append right | O(1) | O(1) |
| Pop right | O(1) | O(1) |
| Append left | O(n) | O(1) |
| Pop left | O(n) | O(1) |
| Random access | O(1) | O(n) |
| Length check | O(1) | O(1) |

### Example Use Cases

* ✅ Use **lists** for **stack implementations** (LIFO).
* ✅ Use **deques** for **queue implementations** (FIFO).
* ✅ Use **lists** when you need to **frequently access elements by position**.
* ✅ Use **deques** when you need to **frequently add/remove from both ends**.

## Tinh huong mua hang: pessimistic lock and optimistic lock
https://aistudio.google.com/prompts/new_chat

## What is Lazy Loading in DB?

https://chat.deepseek.com/a/chat/s/f15434dc-9615-4856-a804-135d30bfdf1d

## Dạng thuật toán hay gặp
- DP
- BFS-DFS Tree
- Recursion
- Binary Search
- Sliding window
- 2 pointer
- HASHING