CAP Theorem phát biểu rằng một hệ thống phân tán chỉ có thể đảm bảo đồng thời tối đa 2 trong 3 thuộc tính: Consistency (tính nhất quán – mọi node trả về dữ liệu mới nhất), Availability (tính sẵn sàng – mọi request đều nhận được response), và Partition Tolerance (chịu lỗi phân vùng – hệ thống tiếp tục hoạt động dù mạng bị chia cắt).

Trong thực tế, Partition Tolerance luôn cần thiết vì lỗi mạng là không thể tránh khỏi, nên lựa chọn thực sự là giữa CP (chọn consistency, hi sinh availability) và AP (chọn availability, hi sinh consistency).

Ví dụ: HBase, Zookeeper là CP; Cassandra, DynamoDB là AP; RDBMS truyền thống là CA (chỉ dùng trong môi trường không phân tán). Khi thiết kế, cần xác định nghiệp vụ ưu tiên gì: hệ thống ngân hàng cần CP, còn mạng xã hội có thể chấp nhận AP với eventual consistency.

ACID (Atomicity, Consistency, Isolation, Durability) là tập hợp thuộc tính đảm bảo transaction trong RDBMS luôn đáng tin cậy: toàn bộ transaction thành công hoặc rollback hoàn toàn, dữ liệu luôn hợp lệ, các transaction cô lập nhau, và dữ liệu đã commit không bao giờ mất.

BASE (Basically Available, Soft state, Eventually consistent) là mô hình của hệ thống NoSQL phân tán: hệ thống cơ bản luôn available, trạng thái có thể thay đổi theo thời gian, và cuối cùng sẽ đạt trạng thái nhất quán.

ACID phù hợp cho giao dịch tài chính, đặt hàng, bất kỳ nghiệp vụ nào yêu cầu tính chính xác tuyệt đối. BASE phù hợp cho hệ thống cần scale lớn như mạng xã hội, analytics, giỏ hàng e-commerce – nơi đôi khi đọc dữ liệu hơi cũ vẫn chấp nhận được để đổi lấy hiệu năng và khả năng mở rộng.

Vertical Scaling (scale up) là nâng cấp phần cứng của một máy chủ duy nhất: tăng CPU, RAM, SSD – đơn giản, không cần thay đổi code, nhưng bị giới hạn bởi phần cứng tối đa và tạo ra single point of failure.

Horizontal Scaling (scale out) là thêm nhiều máy chủ vào hệ thống, phân phối tải qua load balancer – không giới hạn lý thuyết, fault-tolerant hơn, nhưng phức tạp hơn vì cần xử lý distributed state, session management, và data consistency.

Vertical scaling phù hợp khi muốn giải pháp nhanh cho hệ thống nhỏ/trung bình, hoặc cho database (dễ scale hơn application). Horizontal scaling là lựa chọn dài hạn cho hệ thống lớn như Netflix, Google – stateless services dễ scale ngang, trong khi database cần sharding hoặc replica để scale ngang hiệu quả.

Load Balancer là thành phần đứng giữa client và các server, phân phối incoming requests để không có server nào bị quá tải, đồng thời tăng availability bằng cách redirect traffic khi có server bị lỗi.

• Các thuật toán phổ biến: Round Robin (luân phiên tuần tự – đơn giản nhưng không quan tâm trọng tải thực tế), Weighted Round Robin (gán trọng số theo capacity), Least Connections (gửi đến server ít connection nhất – tốt khi request có thời gian xử lý khác nhau), IP Hash (hash IP client để cùng client luôn đến cùng server – hữu ích cho session stickiness), Least Response Time (chọn server nhanh nhất).
• Layer 4 LB hoạt động ở transport layer (TCP/UDP), nhanh hơn nhưng ít thông minh hơn; Layer 7 LB hoạt động ở application layer, có thể route dựa trên URL, header, cookie – linh hoạt hơn nhưng overhead cao hơn.
• AWS ALB, Nginx, HAProxy là các giải pháp phổ biến.

CDN (Content Delivery Network) là mạng lưới các server phân tán địa lý, lưu trữ bản sao (cache) của static content (hình ảnh, JS, CSS, video) tại các edge nodes gần người dùng nhất.

• Khi user request một file, CDN route request đến edge node gần nhất thay vì origin server, giảm latency đáng kể – ví dụ user ở Việt Nam truy cập CDN node Singapore thay vì origin server ở US.
• Ngoài latency, CDN còn giảm tải cho origin server, tăng throughput toàn cầu, có built-in DDoS protection, và cải thiện availability (cache vẫn serve được khi origin tạm thời down).
• CDN phù hợp nhất cho static assets và video streaming; dynamic content cũng có thể cache nếu dùng Edge Computing (Cloudflare Workers, Vercel Edge).
• Các CDN lớn: Cloudflare, AWS CloudFront, Akamai, Fastly.

Forward Proxy đứng phía trước client, đại diện cho client gửi request ra ngoài – client biết về proxy, nhưng server ngoài không biết request thực sự đến từ đâu.

• Dùng để: bypass geo-restriction, ẩn IP client, filter nội dung trong corporate network, caching outbound requests (giảm bandwidth).
• Reverse Proxy đứng phía trước server, đại diện cho server nhận request từ client – client nghĩ mình đang nói chuyện với server thực, không biết có proxy ở giữa.
• Dùng để: load balancing, SSL termination, caching, rate limiting, authentication, ẩn cấu trúc internal network.
• Nginx và HAProxy thường đóng vai trò reverse proxy trong production; Squid là forward proxy phổ biến.
• API Gateway về bản chất là một reverse proxy chuyên biệt với thêm tính năng như auth, routing, transformation.

Latency là thời gian để hoàn thành một request đơn lẻ (đo bằng ms) – thấp là tốt, thể hiện độ nhanh nhạy của hệ thống. Throughput là số lượng requests/operations hệ thống xử lý được trong một đơn vị thời gian (requests/second, transactions/second) – cao là tốt, thể hiện năng lực của hệ thống.

Trade-off xảy ra khi: batching tăng throughput nhưng tăng latency; caching tăng throughput nhưng có thể tăng latency cho cache miss; thêm queue buffer tăng throughput nhưng tăng latency. Trong thực tế, cần xác định SLA: hệ thống real-time gaming cần latency thấp dưới 50ms; hệ thống ETL batch cần throughput cao hơn. Benchmarking nên đo P50, P95, P99 latency để hiểu tail latency, không chỉ average.

Các mô hình consistency phổ biến:

• Strong Consistency (Linearizability): sau khi write thành công, mọi read sau đó đều thấy giá trị mới nhất – dễ lập trình nhất nhưng latency cao nhất vì cần coordination giữa các node.
• Eventual Consistency: dữ liệu sẽ nhất quán sau một khoảng thời gian, nhưng tạm thời có thể đọc dữ liệu cũ – được dùng trong Cassandra, DynamoDB, DNS.
• Read-your-writes Consistency: sau khi user write, chính user đó luôn đọc được dữ liệu mới nhất (dù user khác chưa thấy) – quan trọng cho UX tốt trong social media.
• Causal Consistency: các operation có quan hệ nhân quả được nhìn thấy theo đúng thứ tự (A post → B comment → mọi người thấy comment sau post).
• Monotonic Read: user không bao giờ thấy dữ liệu quay ngược thời gian (không đọc v2 rồi đọc v1).

Lựa chọn consistency model ảnh hưởng trực tiếp đến latency, availability và trải nghiệm người dùng.

Có nhiều tầng caching cho frontend application, mỗi tầng phục vụ mục đích khác nhau. Tầng trình duyệt dùng HTTP headers như Cache-Control và ETag để cache tài nguyên tĩnh (JS, CSS, images), giúp giảm network requests khi user quay lại trang.

Tầng ứng dụng dùng React Query hoặc SWR với chiến lược stale-while-revalidate để cache dữ liệu API — hiển thị data cũ ngay lập tức rồi cập nhật phía sau, mang lại trải nghiệm nhanh cho user. Service Worker cho phép xây dựng ứng dụng offline-first bằng cách cache resources trong Cache API.

Ngoài ra còn localStorage cho user preferences, SessionStorage cho form drafts tạm thời, IndexedDB cho tập dữ liệu lớn cần truy vấn, và CDN cho static assets giúp giảm latency theo vùng địa lý.

Sharding là kỹ thuật chia dữ liệu của một database thành nhiều phần nhỏ hơn (shards), mỗi shard nằm trên một database server riêng, cho phép scale ngang khi dữ liệu vượt quá capacity của một server.

Các chiến lược:
- Range-based sharding: chia theo range của key (user_id 1-1M trên shard 1) – dễ implement nhưng dễ tạo hot spot.
- Hash-based sharding: hash key để phân phối đều – tránh hot spot nhưng khó range query.
- Directory-based sharding: lookup table ánh xạ key → shard – linh hoạt nhất nhưng thêm lookup overhead.
- Geographic sharding: chia theo region – tốt cho compliance và latency.

Thách thức: cross-shard joins tốn kém, distributed transactions phức tạp, rebalancing khi thêm shard khó. Dùng sharding khi đã tối ưu hết cách khác (index, caching, read replicas) và dataset thực sự vượt quá TB.

Read Replica là bản sao của primary database, chỉ nhận read queries trong khi primary (master) nhận tất cả write queries – asynchronous replication đồng bộ dữ liệu từ primary sang replica.

Lợi ích: giảm read load trên primary (80-90% workload thường là read), cho phép scale read throughput bằng cách thêm replicas, dùng replica cho analytics/reporting mà không ảnh hưởng production. AWS RDS, PostgreSQL, MySQL đều hỗ trợ read replicas dễ dàng. Hạn chế quan trọng: replication lag – replica có thể chậm hơn primary vài ms đến vài giây, nên có thể đọc stale data (eventual consistency); cần application-level logic để route read vs write queries; failover tự động cần configuration thêm; write vẫn là bottleneck vì chỉ có một primary. Giải pháp cho write bottleneck là sharding hoặc multi-master replication (phức tạp hơn vì conflict resolution).

Cache-aside (Lazy Loading): application tự quản lý cache – trước tiên check cache, nếu miss thì đọc từ DB và populate cache (cache-aside pattern).

• Ưu: chỉ cache dữ liệu thực sự được đọc, cache failure không block read; Nhược: cache miss đầu tiên luôn có extra latency, dữ liệu cache có thể stale nếu DB được update trực tiếp.
• Write-through: mỗi write đồng thời cập nhật cả cache và DB trước khi trả response.
• Ưu: cache luôn fresh, không bao giờ stale; Nhược: write latency cao hơn, cache dữ liệu ít được đọc lãng phí memory.
• Write-back (Write-behind): write chỉ vào cache trước, trả response ngay, sau đó async flush xuống DB.
• Ưu: write latency rất thấp, tốt cho write-heavy workloads; Nhược: data loss risk nếu cache crash trước khi flush, phức tạp hơn.
• Redis thường dùng cho cả 3 pattern; cache-aside là phổ biến nhất trong thực tế vì đơn giản và phù hợp hầu hết use case.

Rate Limiting là kỹ thuật kiểm soát tần suất request từ một client/IP/user để bảo vệ hệ thống khỏi abuse, DDoS, và đảm bảo fair usage.

Các thuật toán:
- Token Bucket – bucket chứa tokens, mỗi request tiêu 1 token, tokens được refill theo rate cố định; cho phép burst ngắn.
- Leaky Bucket – requests được xử lý ở rate cố định; smooths out bursts nhưng không cho phép burst.
- Fixed Window Counter – đếm request trong window cố định (mỗi phút); đơn giản nhưng có boundary problem.
- Sliding Window Log – lưu timestamp của mỗi request, chính xác nhất nhưng tốn memory.
- Sliding Window Counter – kết hợp Fixed Window + sliding, cân bằng tốt.

Implementation: Redis với INCR + EXPIRE cho distributed rate limiting; Nginx module; API Gateway built-in (AWS API GW, Kong). Trả về 429 Too Many Requests với Retry-After header khi vượt limit.

Connection Pooling duy trì sẵn một pool các kết nối đã được khởi tạo; application lấy connection từ pool và trả lại sau khi dùng xong — thay vì mở/đóng từng kết nối mới với overhead TCP handshake + authentication (20-100ms/lần).

Lợi ích: giảm latency đáng kể, giới hạn số connection đến DB (PostgreSQL thường giới hạn max_connections ~100-500), tăng throughput tổng thể. Pool size quan trọng: quá nhỏ gây bottleneck, quá lớn gây OOM hoặc quá tải DB. Công thức sizing phổ biến từ PostgreSQL Wiki: pool_size ≈ (core_count * 2) + effective_spindle_count — đây là gợi ý từ phía DB server, không phải từ PgBouncer cụ thể; PgBouncer khuyến nghị pool_size dựa trên max_connections và concurrency thực tế. Công cụ phổ biến: PgBouncer (PostgreSQL), HikariCP (Java), pg-pool (Node.js).

CQRS (Command Query Responsibility Segregation) là pattern tách biệt hoàn toàn model đọc (Query) và model ghi (Command) – thay vì một model dùng cho cả CRUD. Command side xử lý mutations và thường dùng domain model phức tạp; Query side tối ưu cho read và có thể dùng denormalized view riêng.

Lợi ích: Read model có thể scale độc lập với Write model; Query side có thể dùng database khác (Elasticsearch cho search, Redis cho cache); mỗi side được tối ưu riêng. Thường kết hợp với Event Sourcing: mỗi Command tạo ra Events, Events cập nhật Read Model (eventual consistency). Phù hợp khi: read/write ratio không cân bằng, domain logic phức tạp, cần nhiều dạng read views khác nhau. Thách thức: eventual consistency giữa write và read side; operational complexity tăng; debugging khó hơn; không phù hợp cho CRUD đơn giản. Ví dụ thực tế: e-commerce – order placement (Command) và order listing dashboard (Query) dùng store riêng biệt.

Event Sourcing là pattern lưu trữ mọi thay đổi trạng thái của application dưới dạng chuỗi immutable events thay vì chỉ lưu trạng thái hiện tại – giống như transaction log của bank hơn là số dư hiện tại.

Ví dụ: thay vì lưu account.balance = 1000, lưu [Deposited(500), Deposited(700), Withdrew(200)] – số dư là kết quả replay của events.

Lợi ích: complete audit trail miễn phí, có thể rebuild state tại bất kỳ điểm nào trong lịch sử, time-travel debugging, dễ tích hợp với CQRS và projections, event stream là nguồn sự thật duy nhất. Hạn chế: querying current state cần replay (giải quyết bằng snapshots), event schema evolution phức tạp khi domain thay đổi, storage tốn hơn, learning curve cao. Phù hợp cho: banking/fintech (audit trail bắt buộc), booking systems, domain-driven design với complex business rules. EventStoreDB là database chuyên biệt cho Event Sourcing; có thể implement trên PostgreSQL, Kafka cũng được.

Stateful services yêu cầu externalize state; các lựa chọn chính là Sticky Sessions, Externalized Store (Redis), và JWT — mỗi cách có trade-off riêng về complexity và failover.

• Sticky Sessions: load balancer route cùng user về cùng server dựa trên cookie — đơn giản nhưng tạo uneven load và failover khó.
• Externalized Session Store: lưu session trong Redis/Memcached thay vì in-memory — mọi instance đọc được, dễ scale và failover.
• JWT Tokens: encode state vào token, server không lưu state — hoàn toàn stateless nhưng không thể revoke trước khi expire (giải quyết bằng blacklist).
• Database-backed Sessions: lưu session trong DB — đơn giản nhưng chậm hơn Redis.

Thực tế: JWT cho authentication + Redis cho session data ngắn hạn là pattern phổ biến nhất.

Monolith là toàn bộ application được deploy như một unit duy nhất – đơn giản để develop, test, deploy ban đầu, không có network overhead giữa components. Microservices chia application thành nhiều services nhỏ, độc lập, mỗi service có database riêng và được deploy độc lập – cho phép scale từng service riêng, team độc lập, polyglot tech stack.

Microservices không phải lúc nào cũng tốt hơn: overhead của distributed systems (network latency, distributed transactions, service discovery, observability) rất lớn. Nên bắt đầu với Monolith hoặc Modular Monolith (monolith với boundaries rõ ràng).

Chỉ migrate sang microservices khi: team lớn (>50 engineers) và bottleneck khi deploy, các module có nhu cầu scale khác nhau rõ rệt, cần polyglot technology. Martin Fowler khuyên: 'Don't start with microservices' – xây dựng monolith tốt trước, sau đó tách dần theo domain boundaries (DDD Bounded Contexts).

API Gateway là single entry point cho tất cả client requests đến microservices – hoạt động như reverse proxy với nhiều tính năng bổ sung. Vai trò: routing (forward request đến đúng service), authentication/authorization (centralized auth thay vì mỗi service tự verify), rate limiting, SSL termination, request/response transformation, API versioning, caching.

Lợi ích: client chỉ cần biết một endpoint thay vì nhiều service URLs; giảm round trips với request aggregation (BFF pattern – Backend for Frontend); dễ thêm cross-cutting concerns mà không sửa services. Hạn chế: single point of failure nếu không có HA setup; có thể trở thành bottleneck; thêm latency; có thể tạo coupling nếu overloaded với logic. Phân biệt API Gateway vs Service Mesh: API Gateway xử lý North-South traffic (external → internal), Service Mesh xử lý East-West traffic (service → service). Giải pháp phổ biến: AWS API Gateway, Kong, Nginx, Traefik, Envoy.

Service Mesh là infrastructure layer xử lý service-to-service communication trong microservices, thường được implement qua sidecar proxy pattern (mỗi service pod có một proxy container đi kèm).

• Service Mesh cung cấp: mTLS (mutual TLS) cho encrypted communication giữa services, load balancing, circuit breaking, retry logic, timeout, distributed tracing, metrics collection – tất cả mà không cần sửa application code.
• Vấn đề Service Mesh giải quyết: khi có hàng chục microservices, implement networking concerns trong mỗi service (bằng library) rất khó maintain, tốn công, dễ inconsistent.
• Service Mesh chuyển những concerns này ra infrastructure layer.
• Istio (với Envoy sidecar) và Linkerd là hai giải pháp phổ biến nhất.
• Trade-off: operational complexity rất cao, Istio đặc biệt nặng và có learning curve lớn – chỉ phù hợp khi có đủ platform engineering team.
• Nhiều tổ chức chọn giải pháp đơn giản hơn như Consul Connect hoặc AWS App Mesh.

Circuit Breaker là pattern bảo vệ hệ thống khỏi cascading failures khi một dependency bị lỗi – lấy cảm hứng từ cầu dao điện.

• Hoạt động qua 3 states: Closed (hoạt động bình thường, theo dõi failure rate), Open (sau khi failure rate vượt threshold, tất cả requests đều fail fast ngay lập tức mà không gọi service lỗi – cho service thời gian recover), Half-Open (sau timeout, cho một số requests thử đến service, nếu thành công thì đóng lại, nếu thất bại thì mở lại).

Ví dụ không có Circuit Breaker: Payment Service gọi Fraud Detection Service bị chậm → threads bị block chờ timeout → thread pool exhaustion → Payment Service cũng down → cascading failure lan rộng.

• Với Circuit Breaker: sau N failures, mở circuit, fail fast với cached response hoặc fallback → hệ thống vẫn partially functional.
• Netflix Hystrix là library phổ biến (hiện maintenance mode), Resilience4j là lựa chọn hiện đại hơn cho Java; Python có pybreaker; built-in trong Istio Service Mesh.

Trong microservices, mỗi service có database riêng, nên không thể dùng distributed transactions (2PC) – quá phức tạp và tạo tight coupling. Saga Pattern giải quyết bằng cách chia distributed transaction thành chuỗi local transactions, mỗi bước publish event; nếu một bước fail, thực hiện compensating transactions để rollback các bước trước. Ví dụ Order Saga: CreateOrder → ReserveInventory → ProcessPayment → ShipOrder; nếu ProcessPayment fail → UnreserveInventory → CancelOrder.

• Choreography: mỗi service lắng nghe events và tự quyết định hành động tiếp theo – không có coordinator trung tâm, loosely coupled hơn nhưng khó theo dõi flow tổng thể, dễ tạo circular dependencies.
• Orchestration: có một Saga Orchestrator trung tâm điều phối các bước, gửi commands đến từng service – dễ hiểu và debug flow, nhưng orchestrator có thể trở thành bottleneck và chứa nhiều business logic.

Temporal.io, AWS Step Functions là công cụ hỗ trợ orchestration saga.

Event-Driven Architecture (EDA) là kiến trúc nơi các components giao tiếp với nhau qua events (notifications về điều gì đó đã xảy ra) thay vì direct API calls. Producer emit events mà không biết consumer là ai; consumer subscribe và xử lý events async – đạt được loose coupling cao.

Lợi ích: producers và consumers hoàn toàn độc lập (có thể deploy, scale, fail độc lập), dễ thêm consumer mới mà không sửa producer, natural fit cho audit logging và event sourcing, handle high throughput tốt qua buffering. Thách thức: debugging và tracing khó hơn vì flow phi tuyến tính; eventual consistency – consumer có thể xử lý chậm hơn producer; ordering guarantees phức tạp (Kafka đảm bảo ordering trong partition); idempotency – consumer cần handle duplicate events; schema evolution khi event format thay đổi. Patterns quan trọng: dead letter queue cho failed events, event schema registry (Confluent Schema Registry), outbox pattern để đảm bảo atomicity giữa DB write và event publish.

RabbitMQ là traditional message broker (queue-based): messages được push đến consumers, sau khi consumer acknowledge thì message bị xóa, hỗ trợ nhiều messaging patterns (pub/sub, point-to-point, routing với exchanges), tốt cho task queues và RPC. Kafka là distributed event log (log-based): messages được append vào log và retained theo thời gian (không xóa sau consume), consumers tự pull và track offset của mình, hỗ trợ replay messages, designed cho high-throughput (hàng triệu messages/second).

Chọn RabbitMQ khi:
- cần complex routing logic, task distribution, message TTL và priority
- tích hợp với nhiều protocols (AMQP, STOMP, MQTT)
- team nhỏ cần dễ ops

Chọn Kafka khi:
- event streaming và event sourcing, audit log cần retention lâu dài
- multiple consumers cần đọc cùng message độc lập
- high throughput analytics pipeline, real-time data integration

Serverless (FaaS – Function as a Service) là mô hình cloud computing nơi developer chỉ viết code (functions), không quản lý server infrastructure; provider tự động provision, scale, và bill theo actual invocations (pay-per-use). AWS Lambda, Google Cloud Functions, Vercel Functions là các giải pháp phổ biến.

Ưu điểm: zero infrastructure management, auto-scaling từ 0 đến hàng nghìn instances ngay lập tức, cost-effective cho sporadic/unpredictable traffic (không trả tiền khi idle), giảm operational overhead.

Nhược điểm: Cold Start latency — Node/Python thường < 100ms P50 nhờ AWS Lambda Provisioned Concurrency và SnapStart (GA 2023 cho Java), nhưng vẫn là vấn đề nếu không dùng tính năng này; execution time limit (Lambda tối đa 15 phút); vendor lock-in; stateless (mỗi invocation độc lập, phải dùng external store); không phù hợp cho long-running processes.

Phù hợp cho: webhooks, scheduled jobs (cron), event-driven processing (S3 trigger, SQS), APIs với variable traffic. Không phù hợp cho: latency-sensitive real-time APIs cần cold start <10ms, stateful applications.

SQL (Relational DB): dùng khi cần ACID transactions (tài chính, đặt hàng), data có structure rõ ràng và ổn định, cần complex queries với JOINs. PostgreSQL, MySQL là lựa chọn mặc định tốt cho hầu hết applications.

NoSQL chia thành nhiều loại:
- Document DB (MongoDB, Firestore) – flexible schema, tốt cho content management, user profiles
- Key-Value (Redis, DynamoDB) – cực nhanh, tốt cho caching, session, leaderboards
- Column-family (Cassandra, HBase) – write-heavy workloads, time-series, IoT data ở scale lớn
- Graph DB (Neo4j) – relationship-heavy queries, social networks, fraud detection

Quyết định không chỉ là SQL vs NoSQL mà là chọn đúng database cho use case. Polyglot persistence – dùng nhiều database types trong cùng hệ thống – là approach của các hệ thống lớn (Netflix dùng MySQL + Cassandra + Elasticsearch + Redis).

Index là data structure (thường là B-Tree) cho phép database tìm kiếm records nhanh mà không cần full table scan – giảm query time từ O(n) xuống O(log n).

• B-Tree Index: phổ biến nhất, hỗ trợ equality và range queries (=, <, >, BETWEEN, LIKE 'prefix%'), tốt cho high-cardinality columns.
• Hash Index: cực nhanh cho equality lookups (=) nhưng không hỗ trợ range queries, dùng trong memory-optimized tables.
• Composite Index: index trên nhiều columns – thứ tự columns quan trọng (leftmost prefix rule); index (a,b,c) hỗ trợ queries trên (a), (a,b), (a,b,c) nhưng không hỗ trợ chỉ (b) hoặc (c).
• Partial Index: chỉ index một subset của rows (ví dụ WHERE status='active') – nhỏ hơn và hiệu quả hơn.
• Full-Text Index: cho text search.
• GIN/GiST Index (PostgreSQL): cho array, JSONB, geometric data.
• Covering Index: index chứa tất cả columns cần cho query – không cần đọc thêm table rows.

Trade-off: mỗi index tốn storage và làm chậm write (phải cập nhật index); không phải nhiều index là tốt hơn. Dùng EXPLAIN ANALYZE để hiểu query plan trước khi thêm index.

Normalization là quá trình tổ chức database để giảm data redundancy và dependency thông qua các Normal Forms (1NF, 2NF, 3NF, BCNF) – chia data thành nhiều tables liên quan, tránh duplicate data.

Lợi ích: storage hiệu quả, dễ maintain consistency khi update (chỉ cần update một chỗ), ít risk inconsistency.

Nhược điểm: cần nhiều JOINs để reconstruct data, JOINs tốn kém ở scale lớn. Denormalization là cố tình thêm redundant data để tăng read performance – ví dụ lưu username trong bảng posts thay vì JOIN với bảng users mỗi lần query.

Lợi ích: read queries nhanh hơn đáng kể, đơn giản hóa query.

Nhược điểm: duplicate data tốn storage, phức tạp khi update (phải update nhiều chỗ), risk inconsistency. Quyết định: OLTP (transaction processing) thường normalize để đảm bảo data integrity; OLAP (analytics, data warehouse) thường denormalize (star/snowflake schema) để tăng query speed. Với NoSQL Document DB, denormalization là mặc định – embed related data vào document nếu luôn được đọc cùng nhau.

Blob Storage là storage chuyên biệt cho unstructured data (images, video, docs) — dùng thay vì database để tránh làm DB backup lớn và ảnh hưởng query performance. AWS S3, Google Cloud Storage, Azure Blob Storage là các giải pháp phổ biến. Pattern đúng: lưu file lên Blob Storage, chỉ lưu metadata (URL, size, type, owner) trong database.

Thiết kế hệ thống upload file: Client → generate pre-signed URL từ backend → upload trực tiếp lên S3 (bypass server, tránh bandwidth bottleneck) → backend nhận callback/event để cập nhật DB. Tối ưu: dùng CDN (CloudFront) trước S3 để serve files nhanh cho users globally, enable S3 Transfer Acceleration cho upload quốc tế, dùng multipart upload cho files lớn (>100MB). Security: pre-signed URLs với expiration time, bucket policy không public, virus scanning với Lambda trigger. Storage tiers: S3 Standard → S3 IA (Infrequent Access) → S3 Glacier cho archival – giảm cost đáng kể.