Thiết kế & Mở rộng DatabaseDatabase Design & Scaling

Thuộc bộ kiến thức Backend Roadmap.

Tổng quan

Mọi backend không tầm thường rồi cũng sống chết theo database của nó. Phần code ứng dụng bạn viết thường là phần dễ thay đổi nhất; còn tầng dữ liệu mới là nơi tập trung tính đúng đắn, latency và chi phí — và cũng là nơi một quyết định sai lầm khó đảo ngược nhất, bởi bạn không thể chỉ đơn giản redeploy một schema như redeploy một binary. Dữ liệu có tính durable, được chia sẻ, và bị ràng buộc bởi vật lý (disk, network, tốc độ của việc coordination), nên nó chống lại phản xạ “cứ thêm server vào” vốn hiệu quả với tầng app stateless.

Đây là một note mang tính cross-cutting. Nó giả định bạn đã biết cơ bản về việc lưu dữ liệu trong relational database và đã biết NoSQL database như một lựa chọn thay thế. Note tập trung vào tầng nằm giữa code và data store, và vào chuyện gì xảy ra khi một database instance đơn lẻ không còn đủ:

• Cách bạn nói chuyện với database từ code (ORM, query builder, raw SQL) và những cái bẫy đi kèm với abstraction — đặc biệt là N+1 query problem.
• Cách bạn tiến hóa schema một cách an toàn theo thời gian (migration, zero-downtime).
• Cách bạn kết nối hiệu quả (connection pooling).
• Cách bạn scale reads (replication, read replica) và scale writes (sharding/partitioning), cùng mức consistency bạn phải đánh đổi.
• Cách bạn giảm tải cho database (caching, materialized view, CQRS) và suy nghĩ về multi-region cùng các tradeoff của CAP.
• Cách bạn tìm ra phần chậm (EXPLAIN, query profiling, indexing).

Mạch xuyên suốt: scaling là một chuỗi tradeoff, không phải một loạt bản nâng cấp. Mỗi kỹ thuật đem lại cho bạn một thứ (throughput, latency, availability) và bắt bạn trả một thứ khác (consistency, độ phức tạp vận hành, chi phí). Biết được cái giá phải trả chính là kỹ năng.

Kiến thức nền tảng

Các tầng giữa code và disk

1. 01Code ứng dụng
2. 02ORM / Query builder
3. sinh ra SQL
   03Driver + Connection pool
4. tái sử dụng kết nối TCP
   04Databaseparser → planner → executor → storage engine
5. 05Index, buffer pool, WAL, disk

Đa số vấn đề performance không phải là “database chậm”. Chúng thường là: quá nhiều round trip (N+1), không tái sử dụng kết nối (pool exhaustion), thiếu index (full table scan), hoặc một query mà planner không thể tối ưu vì cách ORM viết nó. Bạn debug từ trên xuống nhưng chỗ cần sửa thường nằm ở một trong các tầng này.

Vertical vs horizontal scaling

	Vertical (scale up)	Horizontal (scale out)
Là gì	Máy to hơn: nhiều CPU, RAM, disk NVMe nhanh hơn	Nhiều máy hơn: replica, shard
Ưu	Đơn giản, không cần sửa app, giữ một bản copy nhất quán	Headroom gần như vô hạn, cô lập lỗi
Nhược	Trần cứng, đắt ở mức cao, single point of failure, downtime khi resize	Phức tạp, các bài toán distributed systems (consistency, rebalancing)
Dùng khi	Bạn chưa chạm trần — làm cái này trước	Vertical đã cạn hoặc cần fault tolerance / geo-distribution

Nguyên tắc: vắt kiệt vertical scaling và read replica trước khi shard. Một instance đơn lẻ hiện đại (hàng chục core, hàng trăm GB RAM, NVMe) xử lý được nhiều hơn nhiều so với đa số team tưởng. Sharding là điểm không thể quay đầu về mặt độ phức tạp.

Reads và writes scale theo cách khác nhau

Sự phân biệt này tổ chức toàn bộ chủ đề:

• Reads dễ scale: copy dữ liệu ra (replication) rồi trải các query lên các bản copy. Các read không xung đột với nhau.
• Writes khó scale: mọi bản copy đều phải đồng thuận, nên cuối cùng bạn buộc phải chia nhỏ dữ liệu (partitioning/sharding) để các máy khác nhau sở hữu các row khác nhau. Write xung đột với nhau và cần coordination.

Nếu workload của bạn read-heavy (đa số web app), thì replication + caching đi được rất xa. Nếu nó write-heavy (ingest event, metrics, giao dịch khối lượng lớn), bạn sẽ đối mặt với sharding sớm hơn.

Khái niệm chính

ORM & query builder

Một ORM (Object-Relational Mapper) ánh xạ các row trong database thành object trong ngôn ngữ của bạn: User.find(1) thay vì SELECT * FROM users WHERE id = 1. Một query builder là tầng mỏng hơn — nó dựng SQL bằng code nhưng không giả vờ row là object (db.select().from(users).where(...)). Ví dụ: Prisma, TypeORM, Drizzle (JS/TS); SQLAlchemy, Django ORM (Python); GORM, sqlc, Ent (Go); Hibernate/JPA (Java); ActiveRecord (Ruby).

Lợi ích

• Ít boilerplate; CRUD chỉ trong một dòng.
• Type safety và autocomplete (đặc biệt Prisma, Drizzle, sqlc — vốn sinh type từ schema của bạn).
• Portability giữa các database engine (về lý thuyết).
• Chống SQL injection nhờ parameterize mặc định.
• Tích hợp sẵn migration, relation và validation.

Nhược điểm — leaky abstraction

Một ORM giấu SQL đi cho đến khi nó không giấu được nữa. Abstraction bị rò rỉ ngay khi performance trở nên quan trọng, vì ORM không thể biết ý định của bạn:

• Nó giấu đi việc thực sự có bao nhiêu query chạy (xem N+1 bên dưới).
• Các query báo cáo phức tạp, window function, CTE và LATERAL join thì vụng về hoặc bất khả thi để diễn đạt.
• SQL được sinh ra có thể chưa tối ưu, và bạn không thấy được trừ khi bật query logging.
• “Database portability” phần lớn là huyền thoại một khi bạn dùng bất cứ thứ gì đặc thù của engine.

Khi nào nên chuyển xuống raw SQL

• Query phân tích/báo cáo, aggregation, window function, recursive CTE.
• Thao tác hàng loạt (INSERT ... SELECT, batched upsert) — nơi mà gọi ORM theo từng row sẽ là thảm họa.
• Bất kỳ query nào bạn đã profile output của ORM và thấy nó sai.

ORM tốt luôn cho bạn một lối thoát — hãy dùng nó có chủ đích, giữ nó parameterized, và đặt nó gần model mà nó thuộc về.

# SQLAlchemy: ORM cho 90% trường hợp...
user = session.query(User).filter_by(id=1).one()

# ...và raw SQL (parameterized) cho 10% mà ORM xử lý kém:
rows = session.execute(
    text("""
        SELECT date_trunc('day', created_at) AS day, count(*) AS signups
        FROM users
        WHERE created_at >= :since
        GROUP BY 1
        ORDER BY 1
    """),
    {"since": since},
).all()

// GORM: API cấp cao cho CRUD...
db.First(&user, 1)

// ...và Raw khi cần kiểm soát:
db.Raw(`
  SELECT u.id, u.name, count(o.id) AS orders
  FROM users u LEFT JOIN orders o ON o.user_id = u.id
  GROUP BY u.id, u.name
`).Scan(&results)

N+1 query problem

Đây là bug performance của ORM phổ biến nhất. Bạn fetch một danh sách N parent, rồi lặp và truy cập lazy một relation trên từng cái — kích hoạt 1 query cho danh sách cộng N query cho các con. 100 blog post kèm author của chúng trở thành 101 query.

// N+1 với một ORM (giả/kiểu Prisma)
const posts = await db.post.findMany();          // 1 query
for (const post of posts) {
  const author = await db.user.findUnique({      // N query!
    where: { id: post.authorId },
  });
}

Cách phát hiện

• Bật SQL query logging ở môi trường dev; một trang phát ra hàng trăm câu SELECT ... WHERE id = ? gần như giống hệt nhau là dấu hiệu đặc trưng.
• Công cụ APM/tracing (Datadog, New Relic, OpenTelemetry) đánh dấu các query lặp lại trong mỗi request.
• Đặc thù theo ORM: django-debug-toolbar, SQLAlchemy echo, Prisma query event, gem Bullet (Rails).

Cách sửa

1. Eager loading — bảo ORM load relation ngay từ đầu. Nó thường phát ra một query cho parent và một query IN (...) cho toàn bộ con (tổng 2 query), hoặc một join.
   • Prisma: include. TypeORM: relations / leftJoinAndSelect. SQLAlchemy: selectinload/joinedload. Django: select_related (join, cho FK) / prefetch_related (2 query, cho M2M/reverse). GORM: Preload.
2. Một câu JOIN — khi bạn cần parent+child trong một lần.
3. DataLoader pattern — trong ngữ cảnh GraphQL/batched, một DataLoader gom tất cả lời gọi .load(id) trong một tick rồi phát ra một query gộp, khử trùng lặp key. Cách này giải quyết N+1 tại tầng resolver.

// Đã sửa: eager load — tổng cộng 1 (hoặc 2) query
const posts = await db.post.findMany({
  include: { author: true },
});

# SQLAlchemy: selectinload phát ra 1 query cho posts + 1 query IN cho authors
posts = (
    session.query(Post)
    .options(selectinload(Post.author))
    .all()
)

Nguyên tắc: bất cứ khi nào bạn lặp qua một collection và chạm vào một relation bên trong vòng lặp, bạn đang (hoặc sẽ) có N+1. Hãy load relation trước vòng lặp.

Migration: tiến hóa schema an toàn

Một migration là một thay đổi có version, có thứ tự đối với schema (và đôi khi cả data), được commit vào git và áp dụng nhất quán trên mọi environment. Migration là cách một schema tiến hóa mà không phải chơi trò may rủi với ALTER TABLE thủ công.

• Forward (up) áp dụng thay đổi; backward (down) hoàn tác nó. Không phải migration nào cũng đảo ngược sạch sẽ được (drop một column là mất data) — hãy quyết định đường down một cách có chủ đích.
• Tooling: Prisma Migrate, TypeORM/Knex migration, Alembic (SQLAlchemy), Django migration, golang-migrate / goose, Flyway, Liquibase, Rails migration.

Ví dụ một migration (SQL, không phụ thuộc tool):

-- 20260719120000_add_orders_status.up.sql
ALTER TABLE orders
  ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'pending';

CREATE INDEX CONCURRENTLY idx_orders_status ON orders (status);

-- 20260719120000_add_orders_status.down.sql
DROP INDEX IF EXISTS idx_orders_status;
ALTER TABLE orders DROP COLUMN status;

Zero-downtime migration

Phần khó không phải là SQL — mà là code ứng dụng cũ và mới chạy đồng thời trong lúc rolling deploy, nên schema phải tương thích với cả hai. Hai nguyên tắc:

1. Đừng bao giờ thực hiện một thay đổi phá vỡ (breaking) trong một bước. Dùng pattern expand/contract (parallel change):
   • Expand: thêm column/table mới, để nó nullable hoặc có default. Deploy code ghi vào cả cột cũ lẫn mới.
   • Migrate: backfill các row hiện có theo từng batch.
   • Contract: chuyển read sang cột mới, ngừng ghi cột cũ, rồi drop cột cũ ở một lần deploy sau đó.
2. Tránh các lock chặn traffic. Một câu ADD COLUMN với default không phải hằng số, hoặc CREATE INDEX không có CONCURRENTLY, có thể lock cả table. Dùng CREATE INDEX CONCURRENTLY, thêm column dạng nullable, và backfill theo batch thay vì một UPDATE khổng lồ.

Thao tác	An toàn?	Làm cách này
Thêm column nullable	An toàn	—
Thêm column NOT NULL có default	Rủi ro trên engine cũ (rewrite table)	Thêm nullable → backfill → thêm constraint
Drop column	Phá code cũ vẫn còn đọc nó	Expand/contract; drop cuối cùng
Rename column	Phá cả hai chiều	Thêm mới → dual-write → backfill → drop cũ
CREATE INDEX	Lock write	CREATE INDEX CONCURRENTLY (Postgres)

Connection pooling

Mở một kết nối database rất tốn kém: TCP handshake, TLS, authentication, cấp phát process/thread ở phía backend. Làm điều đó cho mỗi request vừa lãng phí thời gian, vừa tệ hơn nữa là database giới hạn số kết nối đồng thời (Postgres mặc định ~100). Dưới tải cao, hàng nghìn request mỗi cái mở một kết nối sẽ làm cạn giới hạn và database sụp — thường là bức tường scaling đầu tiên mà team đâm phải.

Một connection pool giữ một tập kết nối mở có giới hạn và cho các request mượn, trả lại pool khi xong.

1. requests

   requests

   requests
2. pool: 20 kết nối warmmượn / trả
3. database

• Pool nằm trong app (HikariCP, pgxpool, QueuePool của SQLAlchemy, pool tích hợp sẵn của Prisma) hoặc như một proxy bên ngoài (PgBouncer, RDS Proxy, ProxySQL).
• Sizing: to hơn không phải là tốt hơn. Tổng số kết nối trên tất cả các instance app phải nằm dưới giới hạn của DB. Một công thức khởi điểm phổ biến cho DB bị giới hạn bởi CPU: connections ≈ (số_core * 2) + số_spindle_hiệu_dụng. Hãy đo, đừng đoán.
• Serverless/nhiều instance làm chuyện này trầm trọng: 500 instance Lambda × một pool nhỏ mỗi cái là vượt xa giới hạn. Đặt PgBouncer (chế độ transaction pooling) phía trước, hoặc dùng một data proxy.

Scale reads: replication & read replica

Replication copy dữ liệu từ một leader (primary) sang một hoặc nhiều follower (replica). Hình dạng chuẩn là leader-follower (còn gọi là primary-replica): mọi write đi vào leader; read có thể được trải trên các replica.

        writes
client ────────► Leader ──stream WAL/binlog──► Follower 1 (reads)
                   │                          └► Follower 2 (reads)
                   └── reads (strong)

• Scale read theo chiều ngang; thêm replica là thêm read capacity.
• Cung cấp failover: nếu leader chết, promote một follower lên.
• Cho phép đẩy các read phân tích nặng sang một replica riêng để chúng không làm hại write ở production.

Replication lag & hệ quả về consistency

Replication thường là asynchronous — leader không chờ follower xác nhận. Nên một replica có thể trễ vài mili giây đến vài giây. Điều này tạo ra bug kinh điển:

Một user cập nhật profile (write → leader), app ngay lập tức đọc lại (read → một replica đang lag), và thấy giá trị cũ. “Tôi đã lưu rồi mà nó không lưu!”

Đây là eventual consistency trên read. Cách giảm thiểu:

• Read-your-writes: định tuyến read của một user về leader trong một khoảng thời gian ngắn sau khi họ write (hoặc pin session của họ).
• Synchronous / semi-sync replication cho dữ liệu quan trọng: leader chờ ít nhất một replica ack (an toàn hơn, chậm hơn).
• Giám sát lag (pg_stat_replication, Seconds_Behind_Master) và định tuyến tránh khỏi những replica bị tụt quá xa.

Chế độ replication	Durability/consistency	Write latency	Dùng cho
Asynchronous	Có thể mất write gần đây khi failover; replica lag	Thấp nhất	Mặc định, scale read
Semi-synchronous	Ít nhất một replica đã có nó	Cao hơn	Cân bằng
Synchronous	Không mất data khi lỗi một node	Cao nhất	Write tài chính/quan trọng

Scale writes: sharding & partitioning

Khi một leader đơn lẻ không hấp thụ nổi khối lượng write (hoặc dataset không vừa trên một máy), bạn chia dữ liệu ra nhiều node để mỗi node sở hữu một tập con. Thuật ngữ: partitioning = chia một dataset thành các phần; sharding = partitioning trên các database server riêng biệt. (Partitioning cũng có thể nằm trong một server — ví dụ Postgres declarative partitioning theo ngày.)

Bạn chia theo một partition/shard key. Chiến lược quyết định một row nằm ở đâu:

Chiến lược	Ánh xạ ra sao	Ưu	Nhược
Range	Các dải key → shard (ví dụ A–M, N–Z; hoặc theo ngày)	Range scan hiệu quả; đơn giản	Hotspot — key tuần tự (timestamp, ID auto-increment) dồn hết vào một shard
Hash	hash(key) % N → shard	Phân bố đều, không hotspot	Range query trúng mọi shard; resharding khi N đổi thì đau đớn
Directory / lookup	Một bảng tra cứu ánh xạ key → shard	Linh hoạt, rebalance được bằng cách sửa map	Directory là bottleneck / SPOF; thêm một hop

Liên quan: consistent hashing (và virtual node) giảm lượng data phải di chuyển khi bạn thêm/bớt một shard — chỉ chuyển ~1/N số key thay vì gần như toàn bộ.

Nỗi đau của sharding

• Hotspot: một shard key tệ (hoặc một user “người nổi tiếng”, một tenant khổng lồ) đẩy tải không cân xứng vào một shard. Hãy chọn key có cardinality cao, phân bố đều.
• Query & join xuyên shard trở thành scatter-gather ở tầng ứng dụng; JOIN xuyên shard coi như biến mất.
• Transaction xuyên shard mất ACID của một node; bạn cần saga hoặc two-phase commit (cả hai đều đau đớn).
• Resharding (đổi N) là một trong những thao tác khó nhất trong toàn bộ backend engineering — bạn phải ánh xạ lại và di chuyển vật lý dữ liệu trong khi vẫn phục vụ traffic. Hãy thiết kế key sao cho hiếm khi phải làm việc này.
• ID toàn cục duy nhất: auto-increment không hoạt động xuyên shard. Dùng UUID, ULID, hoặc một scheme như Snowflake ID.

Vì tất cả những điều này: shard sau cùng. Ưu tiên vertical scaling → read replica → caching → partitioning-trong-một-node → và chỉ khi đó mới true sharding. Một số database (Vitess, Citus, CockroachDB, YugabyteDB, MongoDB, Cassandra, DynamoDB) lo sharding giúp bạn và đáng để cân nhắc trước khi tự tay làm.

Giảm tải database: caching, materialized view, CQRS

Query rẻ nhất là query bạn không bao giờ chạy.

• Caching — đặt một store nhanh (Redis/Memcached) hoặc cache in-process phía trước các read tốn kém. Đây là nước đi scaling có đòn bẩy cao nhất cho các hệ read-heavy và có một note riêng: xem Caching về cache-aside, write-through, TTL và invalidation.
• Materialized view — kết quả của một query được lưu lại thành một table và refresh định kỳ (REFRESH MATERIALIZED VIEW, lý tưởng là CONCURRENTLY). Tuyệt vời cho các aggregation/báo cáo tốn kém mà chấp nhận được độ trễ nhẹ (staleness). Khác với view thường, nó được precompute; khác với cache, DB tự quản lý nó.
• CQRS (Command Query Responsibility Segregation, nhìn lướt qua) — tách write model khỏi read model. Write đi vào một store được normalize; một projection denormalized, tối ưu cho read (thường là một table hoặc datastore khác) phục vụ query. Nó loại bỏ tranh chấp read/write và cho phép mỗi bên scale độc lập, đổi lại là eventual consistency và nhiều thành phần hơn. Chỉ dùng đến nó trong các domain phức tạp, scale lớn — không phải mặc định.

Replication pattern & multi-region; tradeoff CAP

Vượt ra ngoài leader-follower một region:

• Multi-leader (multi-master): nhiều node chấp nhận write và replicate cho nhau. Cho phép write latency thấp ở nhiều region, nhưng phát sinh write conflict cần giải quyết (last-write-wins, CRDT, merge ở ứng dụng).
• Leaderless (kiểu Dynamo: Cassandra, DynamoDB, Riak): bất kỳ node nào cũng chấp nhận read/write; consistency được tinh chỉnh bằng quorum — W + R > N cho read “gần như” strong. Availability cao, tunable.

Multi-region thêm vào tốc độ ánh sáng: round trip xuyên region tốn hàng chục đến hàng trăm mili giây. Synchronous replication xuyên lục địa làm write chậm; asynchronous làm failover mất mát. Bạn chọn leader đặt ở đâu (write latency vs. locality) và chấp nhận lag ở nơi khác.

Về căn bản đây chính là CAP theorem: trong một Partition mạng, bạn phải chọn Consistency (từ chối/treo request để giữ đúng đắn — CP) hoặc Availability (phục vụ dữ liệu có thể cũ — AP). Trong thực tế nó là một dải phổ được tinh chỉnh theo từng operation, và PACELC liên quan nhắc bạn rằng ngay cả khi không có partition, bạn vẫn đánh đổi Latency vs. Consistency. Các hệ NoSQL thường mặc định AP; RDBMS truyền thống mặc định CP. Điều này nối trực tiếp với các consistency model được nói đến trong NoSQL database.

Profiling query chậm, EXPLAIN & chiến lược index

Bạn không thể scale cái mình không đo được. Trước khi thêm replica hay shard, hãy làm cho mỗi query rẻ đi.

Tìm query chậm

• Bật slow query log (log_min_duration_statement trong Postgres; slow query log trong MySQL).
• pg_stat_statements (Postgres) tổng hợp những query tốn thời gian nhất trên toàn bộ workload — bắt đầu từ đây.
• Đo thời gian DB theo từng endpoint bằng APM.

Đọc plan với EXPLAIN

EXPLAIN ANALYZE chạy thật query và cho thấy plan thực tế, số row, và thời gian.

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 42 AND status = 'pending';

Chú ý tìm:

• Seq Scan (full table scan) trên một table lớn nơi bạn filter/join → thường là thiếu index.
• Số row ước lượng vs thực tế lệch nhau kinh khủng → statistics cũ (ANALYZE) hoặc plan tệ.
• Nested loop trên số row khổng lồ, hoặc sort/hash tràn ra disk.

Chiến lược index (tóm tắt)

• Index các cột dùng trong WHERE, JOIN, và ORDER BY.
• Composite index tuân theo quy tắc leftmost-prefix: một index trên (user_id, status) phục vụ WHERE user_id = ? và WHERE user_id = ? AND status = ?, nhưng không phục vụ WHERE status = ? một mình. Sắp thứ tự cột theo selectivity/mức độ dùng.
• Covering index: bao gồm mọi cột một query cần để nó không bao giờ phải chạm vào table (Postgres INCLUDE, index-only scan).
• Index tăng tốc read nhưng làm chậm write và tốn storage — mỗi INSERT/UPDATE phải bảo trì mọi index. Đừng over-index.
• Dùng partial index cho các query lệch (WHERE status = 'pending') và nhớ đến cardinality: index một boolean cardinality thấp hiếm khi có ích.

Xem Relational database về internal của index (B-tree, hash, GIN/GiST) và normalization.

Best Practices

Bảng quyết định: kỹ thuật → vấn đề → tradeoff

Kỹ thuật	Vấn đề nó giải quyết	Tradeoff / cái giá
Thêm index	Read chậm / full table scan	Write chậm hơn, tốn storage
Sửa N+1 (eager load)	Quá nhiều round trip mỗi request	Query đơn hơi lớn hơn; phải nhớ mà load
Connection pool / PgBouncer	Cạn kết nối, overhead handshake	Config/vận hành; lưu ý về chế độ pooling (prepared statement)
Vertical scaling	Không đủ CPU/RAM/IO trên một máy	Trần, chi phí, downtime khi resize, vẫn là SPOF
Read replica	Read throughput quá cao cho leader	Replication lag → read cũ (eventual consistency)
Caching (Redis)	Read tốn kém lặp lại	Độ phức tạp invalidation, rủi ro data cũ
Materialized view	Aggregation tốn kém lặp lại	Cũ cho đến khi refresh; chi phí refresh
CQRS	Tranh chấp read/write trong domain phức tạp	Eventual consistency, phức tạp hơn nhiều
Partitioning (một node)	Table khổng lồ, prune dễ theo key/ngày	Chỉ ích khi query filter theo partition key
Sharding	Khối lượng write / dataset vượt một node	Mất join/txn xuyên shard, nỗi đau resharding, hotspot
Multi-region replication	Latency toàn cầu, failover theo region	CAP: consistency vs availability; giải quyết conflict

Nguyên tắc vận hành

• Đo trước đã. Bật query logging và pg_stat_statements trước khi tối ưu. Đa số “chúng ta cần shard” hóa ra là “chúng ta cần một index”.
• Scale theo thứ tự rẻ-đến-đắt: index & sửa N+1 → connection pool → vertical → read replica + cache → partition → shard. Đừng nhảy cóc.
• Thiết kế mọi migration cho zero downtime (expand/contract), kể cả những cái nhỏ — giả định rolling deploy và các phiên bản code lẫn lộn.
• Đừng tin ORM một cách mù quáng. Log SQL được sinh ra ở dev; giữ một lối thoát sang raw SQL cho những query quan trọng.
• Chọn shard/partition key để phân bố đều và theo query pattern; một key tệ rất đắt để thay đổi. Tránh dùng key tuần tự làm shard key duy nhất.
• Giả định replication lag luôn tồn tại. Định tuyến read-your-writes về leader; giám sát lag và né các replica cũ.
• Giới hạn và giám sát số kết nối trên tất cả các instance app so với giới hạn của DB — đây là một nguyên nhân hàng đầu gây sự cố production.
• Backfill theo batch, đừng bao giờ chạy một UPDATE/DELETE khổng lồ khóa cả table hoặc làm phình WAL.
• Giữ write path gọn nhẹ. Đẩy các read tốn kém sang replica, cache và materialized view để leader làm đúng việc mà chỉ nó làm được: chấp nhận write một cách an toàn.

Để hiểu điều này khớp vào bức tranh lớn hơn về hệ thống resilient như thế nào, xem Scalability & Reliability.

Tài liệu tham khảo

• Designing Data-Intensive Applications — Martin Kleppmann (O’Reilly) — cuốn sách kinh điển về replication, partitioning và consistency.
• PostgreSQL Documentation — High Availability, Load Balancing, and Replication
• PostgreSQL Documentation — Using EXPLAIN
• Use The Index, Luke! — SQL indexing và performance
• PgBouncer — Connection pooler nhẹ cho PostgreSQL
• Prisma — Relation queries & tránh N+1
• Vitess — Tài liệu Sharding
• Martin Fowler — CQRS

# SQLAlchemy: ORM for the 90% case...
user = session.query(User).filter_by(id=1).one()

# ...and raw SQL (parameterized) for the 10% the ORM handles poorly:
rows = session.execute(
    text("""
        SELECT date_trunc('day', created_at) AS day, count(*) AS signups
        FROM users
        WHERE created_at >= :since
        GROUP BY 1
        ORDER BY 1
    """),
    {"since": since},
).all()

// GORM: high-level API for CRUD...
db.First(&user, 1)

// ...and Raw when you need control:
db.Raw(`
  SELECT u.id, u.name, count(o.id) AS orders
  FROM users u LEFT JOIN orders o ON o.user_id = u.id
  GROUP BY u.id, u.name
`).Scan(&results)

// N+1 with an ORM (pseudo/Prisma-like)
const posts = await db.post.findMany();          // 1 query
for (const post of posts) {
  const author = await db.user.findUnique({      // N queries!
    where: { id: post.authorId },
  });
}

// Fixed: eager load — 1 (or 2) queries total
const posts = await db.post.findMany({
  include: { author: true },
});

# SQLAlchemy: selectinload issues 1 query for posts + 1 IN-query for authors
posts = (
    session.query(Post)
    .options(selectinload(Post.author))
    .all()
)

-- 20260719120000_add_orders_status.up.sql
ALTER TABLE orders
  ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'pending';

CREATE INDEX CONCURRENTLY idx_orders_status ON orders (status);

-- 20260719120000_add_orders_status.down.sql
DROP INDEX IF EXISTS idx_orders_status;
ALTER TABLE orders DROP COLUMN status;

        writes
client ────────► Leader ──WAL/binlog stream──► Follower 1 (reads)
                   │                          └► Follower 2 (reads)
                   └── reads (strong)

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 42 AND status = 'pending';