9 pattern hệ phân tán 9 distributed systems patterns

Chín pattern, ba câu hỏi, không cái nào miễn phí

Nine patterns, three questions, none of them free

Chín pattern này không phải một danh sách. Chúng trả lời ba câu hỏi khác nhau: dữ liệu nằm ở đâu, các dịch vụ chịu lỗi của nhau thế nào, và ai được quyền quyết định khi các node bất đồng. Chọn sai nhóm thì càng làm kỹ càng sai xa.

These nine patterns are not a list. They answer three different questions: where the data lives, how services survive each other's failures, and who decides when nodes disagree. Pick the wrong group and the better you execute, the further off you end up.

dữ liệu nằm ở đâuwhere data liveschịu lỗi thế nàosurviving failureai được quyết địnhwho gets to decide Replication1 Sharding2 Consistent Hashing3 Pub/Sub4 Retry with Backoff5 Circuit Breaker6 Leader Election7 Quorum Reads/Writes8 Saga9

màu mã hoá nhóm bài toán, không phải trang trí

colour encodes the problem group, not decoration

Đọc mục này trước Read this first

Khi nào bạn không cần pattern nào cả

When you need none of this

Một PostgreSQL trên một máy, có backup và point-in-time recovery, một replica dự phòng để failover. Một máy 16 vCPU / 64 GB xử lý được vài nghìn truy vấn đọc mỗi giây và hàng trăm giao dịch ghi mỗi giây. Rất nhiều sản phẩm có doanh thu thật chưa bao giờ chạm trần đó. Chỉ vượt baseline khi có số đo: dữ liệu vượt đĩa một máy, ghi vẫn nghẽn sau khi đã nâng cấp hết cỡ, RTO phải dưới vài phút, hoặc nhiều team đang chặn nhau trên một database. Không có tín hiệu nào ở trên thì mọi pattern bên dưới đều làm hệ thống của bạn tệ đi.

One PostgreSQL on one machine, with backups and point-in-time recovery, plus a standby replica for failover. A 16 vCPU / 64 GB machine handles a few thousand reads per second and several hundred write transactions per second. Plenty of products with real revenue never approach that ceiling. Leave the baseline only on measurements: data outgrowing one disk, writes still bottlenecked after scaling up, an RTO under a few minutes, or teams blocking each other on one database. Without one of those signals, every pattern below will make your system worse.

Chọn cái nào — 30 giây

Which one — in 30 seconds

Vấn đề của bạn là gì?
│
├─ Đọc quá tải, ghi vẫn ổn ──────────────► Replication
│
├─ Ghi quá tải / dữ liệu không vừa 1 máy ► Sharding
│    └─ và cụm co giãn thường xuyên ────► + Consistent Hashing
│
├─ Cache cần rebalance êm ───────────────► Consistent Hashing
│
├─ Một hành động kéo theo N việc phụ ────► Pub/Sub
│
├─ Lời gọi ra ngoài thỉnh thoảng lỗi ────► Retry with Backoff
│    └─ và có lúc lỗi kéo dài nhiều phút ► + Circuit Breaker
│
├─ Một việc chỉ được chạy đúng một nơi ──► Leader Election
│
├─ Cần nhất quán khác nhau theo truy vấn ► Quorum Reads/Writes
│
└─ Quy trình trải trên nhiều database ───► Saga
What is actually hurting?
│
├─ Reads overloaded, writes fine ────────► Replication
│
├─ Writes overloaded / data won't fit ───► Sharding
│    └─ and the cluster resizes often ──► + Consistent Hashing
│
├─ Cache needs smooth rebalancing ───────► Consistent Hashing
│
├─ One action triggers N side jobs ──────► Pub/Sub
│
├─ Outbound calls fail intermittently ───► Retry with Backoff
│    └─ and sometimes fail for minutes ─► + Circuit Breaker
│
├─ A job must run in exactly one place ──► Leader Election
│
├─ Consistency must vary per query ──────► Quorum Reads/Writes
│
└─ A process spans several databases ────► Saga

Hai cặp gần như luôn đi cùng nhau: Retry + Circuit Breaker, và Sharding + Consistent Hashing. Dùng lẻ vế đầu của mỗi cặp là lỗi phổ biến nhất ở đây.

Two pairs almost always travel together: Retry + Circuit Breaker, and Sharding + Consistent Hashing. Adopting only the first half of either is the most common mistake here.

Phân bố & sắp đặt dữ liệuData distribution & placement

Replication

Phân bố & sắp đặt dữ liệuData distribution & placement

Nhiều bản sao giống nhau của cùng một tập dữ liệu. Một node nhận ghi, các node còn lại sao chép lại và phục vụ đọc.Several identical copies of one dataset. One node takes writes, the rest copy them and serve reads.

Chọn replication là đổi tính nhất quán tức thời khi đọc lấy khả năng chịu lỗi và băng thông đọc.Choosing replication trades read-your-write immediacy for fault tolerance and read bandwidth.

Dùng choGood for

  • Sản phẩm đọc nhiều hơn ghi rất nhiều
  • Tách báo cáo và phân tích nặng khỏi đường phục vụ
  • Dự phòng thảm hoạ và đặt replica gần người dùng
  • Products that read far more than they write
  • Moving reporting and analytics off the serving path
  • Disaster recovery and replicas placed near users

ĐượcYou gain

  • Thông lượng đọc tăng gần tuyến tính
  • RTO còn vài chục giây nếu failover tự động
  • Backup không đụng vào tải sản xuất
  • Read throughput scales close to linearly
  • RTO drops to tens of seconds with automated failover
  • Backups stop touching production load

MấtYou lose

  • Replication lag: đọc ra dữ liệu cũ
  • Bất đồng bộ thì primary chết là mất dữ liệu
  • Ghi không hề được scale — vẫn một máy
  • Replication lag serves stale reads
  • Async replication means data loss if the primary dies
  • Writes don't scale at all — still one machine

Dấu hiệu nhận biếtHow to spot it CPU của primary cạn vì SELECT, không phải vì INSERT.The primary's CPU is burned by SELECT, not by INSERT.

Sharding

Phân bố & sắp đặt dữ liệuData distribution & placement

Chia dữ liệu thành các tập rời nhau theo một khoá. Mỗi node giữ một phần, không phải toàn bộ.Splitting data into disjoint sets by key. Each node holds part of the data, not all of it.

Chọn sharding là đổi khả năng truy vấn tuỳ ý và giao dịch trên một máy lấy quy mô ghi gần như không giới hạn.Choosing sharding trades arbitrary querying and single-machine transactions for write capacity with almost no ceiling.

Dùng choGood for

  • Ghi vượt trần một máy sau khi đã nâng cấp hết cỡ
  • Dataset lớn hơn đĩa, index lớn hơn RAM
  • SaaS nhiều tenant, time-series, log
  • Writes past a single machine's ceiling after scaling up
  • Datasets larger than disk, indexes larger than RAM
  • Multi-tenant SaaS, time series, logs

ĐượcYou gain

  • Ghi và dung lượng mở rộng ngang, gần như không trần
  • Index nhỏ hơn nên truy vấn nhanh hơn
  • Một shard hỏng chỉ ảnh hưởng 1/N người dùng
  • Write and storage capacity scale out with no real ceiling
  • Smaller indexes mean faster queries
  • A broken shard affects only 1/N of users

MấtYou lose

  • JOIN và transaction xuyên shard coi như mất
  • Shard key lệch thì một node gánh 60% tải
  • Đổi shard key sau này là dự án nhiều tháng
  • Cross-shard joins and transactions are gone
  • A skewed key leaves one node with 60% of the load
  • Changing the shard key later is a multi-month project

Dấu hiệu nhận biếtHow to spot it Đã mua máy to nhất nhà cung cấp có mà vẫn nghẽn ghi.You bought the biggest instance available and writes still bottleneck.

Consistent Hashing

Phân bố & sắp đặt dữ liệuData distribution & placement

Ánh xạ khoá sang node sao cho thêm hoặc bớt node chỉ di chuyển khoảng 1/N số khoá, thay vì gần như toàn bộ.Mapping keys to nodes so that adding or removing a node moves about 1/N of the keys instead of nearly all of them.

Chọn consistent hashing là đổi sự đơn giản của phép chia dư lấy chi phí rebalance thấp mỗi khi cụm thay đổi kích thước.Choosing consistent hashing trades the simplicity of modulo arithmetic for a low rebalancing cost whenever the cluster resizes.

Dùng choGood for

  • Cụm cache Memcached hoặc Redis sharding phía client
  • Kho dữ liệu tự cân bằng kiểu Dynamo
  • Cân bằng tải dính phiên, CDN chọn origin
  • Memcached clusters and client-side sharded Redis
  • Self-balancing Dynamo-style stores
  • Sticky load balancing, CDN origin selection

ĐượcYou gain

  • Đổi topology chỉ dịch chuyển ~1/N khoá
  • Không cần bảng định tuyến tập trung
  • Với 100–256 vnode, lệch tải dưới khoảng 5%
  • Topology changes move roughly 1/N of keys
  • No central routing table to maintain
  • With 100–256 vnodes, skew stays under about 5%

MấtYou lose

  • Ít vnode thì lệch tải nặng, chỉ lộ ra khi chạy thật
  • Không giải quyết được hot key
  • Client cầm topology cũ ghi vào node sai, im lặng
  • Too few vnodes skews badly, and only in production
  • Does nothing for hot keys
  • A client with a stale topology writes to the wrong node silently

Dấu hiệu nhận biếtHow to spot it Thêm một node vào cụm cache là cache miss gần như toàn bộ.Adding one cache node causes a near-total miss storm.

Giao tiếp & chịu lỗiCommunication & fault tolerance

Pub/Sub

Giao tiếp & chịu lỗiCommunication & fault tolerance

Bên gửi phát sự kiện vào một topic, bên nhận đăng ký. Hai bên không biết nhau và không cần cùng online.A sender publishes events to a topic and receivers subscribe. Neither side knows the other exists or needs to be online.

Chọn pub/sub là đổi khả năng suy luận tuyến tính về một luồng xử lý lấy sự độc lập về nhịp giữa các dịch vụ.Choosing pub/sub trades the ability to reason linearly about a flow for independence in pace between services.

Dùng choGood for

  • Một đơn hàng kéo theo trừ kho, gửi mail, ghi phân tích
  • Tách nhịp giữa dịch vụ nhanh và dịch vụ chậm
  • Hấp thụ đỉnh tải, change data capture, audit log
  • One order triggering stock, email, analytics, reconciliation
  • Decoupling fast services from slow ones
  • Absorbing spikes, change data capture, audit logs

ĐượcYou gain

  • Thêm consumer mới không cần sửa producer
  • Đỉnh tải san phẳng, consumer chậm chỉ làm hàng đợi dài
  • Phát lại được lịch sử sau khi sửa bug
  • New consumers need no producer change
  • Peaks flatten; a slow consumer just grows a queue
  • History is replayable after a consumer fix

MấtYou lose

  • At-least-once: trùng lặp là chuyện bình thường
  • Thứ tự chỉ đúng trong một partition
  • Broker thành một hệ thống phải vận hành riêng
  • At-least-once means duplicates are normal
  • Ordering only holds within a partition
  • The broker becomes a system you have to operate

Dấu hiệu nhận biếtHow to spot it Một hành động kéo theo nhiều việc phụ mà người dùng không cần chờ.One action triggers several jobs the user never waits for.

Retry with Backoff

Giao tiếp & chịu lỗiCommunication & fault tolerance

Thử lại lời gọi thất bại với khoảng chờ tăng theo cấp số nhân, kèm nhiễu ngẫu nhiên để các client không quay lại cùng lúc.Retrying a failed call with an exponentially growing wait plus jitter so clients don't return in lockstep.

Chọn retry là đổi độ trễ ở phần đuôi và tải thêm lên hệ đích lấy tỉ lệ thành công cao hơn trước các lỗi thoáng qua.Choosing retries trades tail latency and extra load on the target for a higher success rate against transient failures.

Dùng choGood for

  • Lỗi mạng thoáng qua và timeout ngẫu nhiên
  • 429 hoặc 503 từ API bên thứ ba
  • Deadlock ở database, dịch vụ vừa deploy xong
  • Transient network errors and random timeouts
  • 429 or 503 from a rate-limiting third party
  • Database deadlocks, services that just deployed

ĐượcYou gain

  • Che gần hết loại lỗi phổ biến nhất, chi phí rất nhỏ
  • Jitter phá vỡ sóng client quay lại đồng loạt
  • Một lớp thư viện, không đổi kiến trúc
  • Absorbs the most common failure class, cheaply
  • Jitter breaks the synchronised return wave
  • One client-library layer, no architectural change

MấtYou lose

  • Retry lồng nhau nhân theo cấp số: 3×3 = 27 request
  • Retry thao tác không idempotent tính tiền hai lần
  • Retry vào dịch vụ quá tải khiến nó không hồi phục nổi
  • Nested retries multiply: 3 × 3 = 27 requests
  • Retrying non-idempotent work charges twice
  • Retrying into an overloaded service prevents recovery

Dấu hiệu nhận biếtHow to spot it Thử lại bằng tay đúng một lần là chạy được.Retrying by hand exactly once makes it work.

Circuit Breaker

Giao tiếp & chịu lỗiCommunication & fault tolerance

Cầu dao đặt trước lời gọi ra ngoài. Vượt ngưỡng lỗi thì mở, mọi lời gọi tiếp theo bị từ chối ngay thay vì chờ timeout.A breaker in front of an outbound call. Past the error threshold it opens and calls fail instantly instead of waiting on a timeout.

Chọn circuit breaker là đổi việc từ chối một phần request lẽ ra vẫn thành công lấy sự sống sót của toàn bộ dịch vụ.Choosing a circuit breaker trades rejecting some requests that would have succeeded for the survival of the whole service.

Dùng choGood for

  • API bên thứ ba: thanh toán, mail, nhà cung cấp dữ liệu
  • Dịch vụ downstream hay tắc dưới tải cao
  • Mọi chỗ có timeout dài và chấp nhận được phương án dự phòng
  • Third-party APIs: payments, mail, data vendors
  • Internal downstreams that stall under load
  • Anywhere with a long timeout and an acceptable fallback

ĐượcYou gain

  • Biến timeout 30 giây thành lỗi 1 mili-giây
  • Giữ thread và connection cho phần còn lại
  • Giảm tải để downstream có cơ hội hồi phục
  • Turns a 30-second timeout into a 1-millisecond error
  • Preserves threads and connections for the rest
  • Sheds load so the downstream can recover

MấtYou lose

  • Ngưỡng sai thì mở nhầm lúc tải thấp
  • Che lỗi quá tốt nên mất tín hiệu nếu không có metric
  • Trạng thái theo từng process, mười pod mười kiểu
  • A bad threshold opens it at low traffic
  • It hides errors so well you lose the signal
  • Per-process state: ten pods, ten different states

Dấu hiệu nhận biếtHow to spot it Một dependency chậm làm cạn thread pool và kéo sập cả chức năng không liên quan.One slow dependency drains the thread pool and takes unrelated features down.

Điều phối & nhất quánCoordination & consistency

Leader Election

Điều phối & nhất quánCoordination & consistency

Cơ chế để một nhóm node thống nhất chọn đúng một node được quyền điều phối, và phát hiện khi node đó chết để bầu lại.A way for a group of nodes to agree on exactly one coordinator, and to detect its death so a new one can be elected.

Chọn leader election là đổi thông lượng và một điểm tập trung lấy tính đúng đắn cho thao tác bắt buộc chỉ một nơi thực hiện.Choosing leader election trades throughput and a centralised point for correctness on operations that must happen exactly once.

Dùng choGood for

  • Job định kỳ chỉ được chạy một nơi dù có 20 pod
  • Chọn primary khi database failover
  • Điều phối rebalance partition hoặc phân chia công việc
  • Scheduled jobs that must run once across 20 pods
  • Choosing the primary during database failover
  • Coordinating partition rebalancing or work assignment

ĐượcYou gain

  • Biến bài toán đồng thời thành bài toán tuần tự
  • Failover tự động trong vài giây
  • Leader giữ được state nóng trong bộ nhớ
  • Turns a concurrency problem into a sequential one
  • Automatic failover within seconds
  • The leader can keep hot state in memory

MấtYou lose

  • Leader là nút cổ chai ghi và điểm chết đơn
  • GC pause dài tạo ra hai leader cùng ghi
  • Phải vận hành thêm một cụm đồng thuận
  • The leader is a write bottleneck and a single point of failure
  • A long GC pause produces two writing leaders
  • You now operate a consensus cluster too

Dấu hiệu nhận biếtHow to spot it Công việc này chạy hai lần thì dữ liệu hỏng, chứ không chỉ tốn thêm tài nguyên.If this job runs twice the data is corrupted, not merely the compute wasted.

Quorum Reads/Writes

Điều phối & nhất quánCoordination & consistency

Quy tắc số phiếu trên N bản sao: ghi cần W bản xác nhận, đọc hỏi R bản. Nếu W + R > N thì đọc luôn thấy ghi mới nhất.A voting rule over N replicas: a write needs W acknowledgements, a read consults R. If W + R > N a read always sees the latest write.

Chọn quorum là đổi độ trễ và băng thông lấy quyền tự tay điều chỉnh mức nhất quán cho từng thao tác.Choosing quorums trades latency and bandwidth for the right to dial consistency per operation.

Dùng choGood for

  • Kho dữ liệu kiểu Dynamo: Cassandra, ScyllaDB, Riak
  • Hệ đa vùng cần chỉnh nhất quán theo từng loại truy vấn
  • Dữ liệu tối quan trọng sống chung với dữ liệu nhất quán cuối
  • Dynamo-style stores: Cassandra, ScyllaDB, Riak
  • Multi-region systems tuning consistency per query type
  • Critical data living inside an eventually consistent store

ĐượcYou gain

  • Chỉnh mức nhất quán theo từng lời gọi
  • Ghi vẫn thành công khi tối đa N−W replica chết
  • Không có leader nên không có failover, không nút cổ chai
  • Consistency tuned per call, not per system
  • Writes survive up to N−W dead replicas
  • No leader means no failover and no write bottleneck

MấtYou lose

  • p99 bị kéo bởi replica chậm nhất trong nhóm W
  • Không cho bạn transaction, cũng không compare-and-set
  • Ghi đồng thời phải tự giải quyết; last-write-wins mất dữ liệu
  • p99 is set by the slowest replica in the W group
  • It gives you no transactions and no compare-and-set
  • Concurrent writes need reconciling; LWW loses data

Dấu hiệu nhận biếtHow to spot it Cần nhất quán mạnh cho 5% truy vấn, còn 95% thì không, và không muốn tách hai hệ thống.You need strong consistency for 5% of queries and not the other 95%.

Saga

Điều phối & nhất quánCoordination & consistency

Quy trình nghiệp vụ chia thành chuỗi giao dịch cục bộ ở nhiều dịch vụ. Bước nào hỏng thì chạy các hành động bù trừ ngược lại.A business process split into local transactions across services. When a step fails, compensating actions run in reverse.

Chọn saga là đổi tính cô lập của transaction lấy khả năng hoàn tất một quy trình xuyên nhiều dịch vụ mà không khoá chúng vào nhau.Choosing a saga trades transactional isolation for the ability to complete a process across services without locking them together.

Dùng choGood for

  • Đặt hàng: giữ kho → tạo đơn → thu tiền → xuất kho
  • Đặt vé máy bay kèm khách sạn kèm xe
  • Quy trình có bước chờ người duyệt kéo dài hàng giờ
  • Order flows: reserve → create → charge → ship
  • Booking a flight plus hotel plus car
  • Processes with a human approval step lasting hours

ĐượcYou gain

  • Giữ tính tất-cả-hoặc-không ở mức nghiệp vụ, không cần 2PC
  • Mỗi dịch vụ vẫn giữ database riêng
  • Bước chờ lâu không giữ khoá database
  • All-or-nothing at the business level without 2PC
  • Each service keeps its own database
  • Long waits hold no database locks

MấtYou lose

  • Không có isolation: hệ khác thấy trạng thái dở dang
  • Bù trừ không phải rollback — hoàn tiền không xoá được phí
  • Bù trừ cũng thất bại được, và khi đó chỉ còn xử lý tay
  • No isolation: others observe half-finished states
  • Compensation isn't rollback — a refund keeps the fee
  • Compensating actions fail too, leaving manual cleanup

Dấu hiệu nhận biếtHow to spot it Muốn viết BEGIN TRANSACTION nhưng dữ liệu nằm ở ba database của ba team.You want BEGIN TRANSACTION but the data sits in three teams' databases.

Bảng đánh đổi

Trade-off table

Vuốt ngang để xem đủ cộtSwipe sideways for the rest of the columns

Pattern Giải bài toán gìProblem it solves Bạn đượcYou gain Bạn mấtYou lose Vận hànhOps cost Lùi lại được?Reversible?
ReplicationĐọc quá tải, cần dự phòngRead overload, need standbyBăng thông đọc, HARead bandwidth, HANhất quán tức thờiRead-your-write immediacyThấpLowDễEasy
ShardingGhi và dung lượng quá trầnWrites and volume past ceilingQuy mô ghiWrite scaleJOIN, transactionJoins, transactionsCaoHighRất khóVery hard
Consistent HashingCụm co giãn thường xuyênCluster resizes oftenRebalance rẻCheap rebalancingSự đơn giảnSimplicityTrung bìnhMediumKhóHard
Pub/SubGhép nối chặt, tải đỉnhTight coupling, load spikesĐộc lập giữa dịch vụService independenceLuồng xử lý dễ hiểuLegible control flowCaoHighTrung bìnhMedium
Retry with BackoffLỗi thoáng quaTransient failuresTỉ lệ thành côngSuccess rateĐộ trễ đuôi, tải thêmTail latency, extra loadRất thấpVery lowRất dễVery easy
Circuit BreakerLỗi kéo dài, cạn tài nguyênSustained failure, resource drainSự sống sót của dịch vụService survivalMột phần request tốtSome good requestsThấpLowRất dễVery easy
Leader ElectionCần đúng một nơi thực hiệnExactly-one executionTính đúng đắnCorrectnessThông lượng, thêm phụ thuộcThroughput, a dependencyTrung bìnhMediumTrung bìnhMedium
Quorum Reads/WritesCần nhất quán tuỳ chỗPer-query consistencyĐiều chỉnh theo truy vấnTunable guaranteesĐộ trễ, băng thôngLatency, bandwidthTrung bìnhMediumTrung bìnhMedium
SagaTransaction xuyên dịch vụCross-service transactionsQuy trình hoàn tất đượcCompletable processesTính cô lậpIsolationCaoHighKhóHard

Đọc cột “Lùi lại được?” trước cột “Bạn được”. Retry sai thì tắt trong năm phút. Shard key sai thì sống chung với nó vài năm.

Read the “Reversible?” column before the “You gain” column. A bad retry policy is switched off in five minutes. A bad shard key is yours for years.

Anti-patterns

Anti-patterns

Vuốt ngang để xem đủ cộtSwipe sideways for the rest of the columns

Sai lầmMistake Vì sao saiWhy it's wrong Sửa thế nàoThe fix
Retry ở mọi tầngRetrying at every layer3 tầng × 3 lần = 27 request cho một hành động3 layers × 3 attempts = 27 requests per actionRetry ở đúng một tầng ngoài cùng; các tầng trong fail fastRetry at one outer layer only; inner layers fail fast
Retry không jitterRetrying without jitterClient đồng loạt quay lại, tạo sóng đè sập dịch vụClients return in lockstep and flatten the serviceFull jitter: random(0, base × 2ⁿ)Full jitter: random(0, base × 2ⁿ)
Đọc replica ngay sau khi ghiReading a replica right after writingReplication lag làm người dùng thấy dữ liệu cũ của chính mìnhLag shows users their own stale dataGhim session vào primary vài giây sau lệnh ghiPin the session to the primary for a few seconds
Shard theo trường trông tự nhiên nhấtSharding on the field that looks naturalTruy vấn nóng không chứa shard key → scatter-gather toàn cụmHot queries lack the key → cluster-wide scatter-gatherChọn key theo đường truy vấn nóng nhất, đo trên dữ liệu thậtChoose the key from the hottest access path, measured on real data
Consumer không idempotentNon-idempotent consumersAt-least-once là mặc định, trùng lặp chắc chắn xảy raAt-least-once is the default; duplicates are certainevent_id + bảng dedup; coi trùng lặp là bình thườngevent_id + dedup table; treat duplicates as normal
Bầu leader không có fencingElection without fencingGC pause tạo ra hai leader cùng ghiA GC pause produces two writing leadersFencing token theo nhiệm kỳ, tài nguyên đích từ chối token cũTerm-based fencing tokens, rejected at the target resource
Last-write-wins cho số đếmLast-write-wins on countersGhi đồng thời làm mất dữ liệu, âm thầm, không logConcurrent writes lose data silently, with no logCounter chuyên dụng, CRDT, hoặc hệ có transactionDedicated counters, CRDTs, or a transactional store
Thu tiền ở bước đầu của sagaCharging first in a sagaBước không bù trừ được nằm trước các bước dễ hỏngThe non-compensatable step sits ahead of fragile onesĐẩy bước không thể lùi xuống cuối chuỗiMove irreversible steps to the end of the chain
Dùng pattern vì sau này sẽ cầnAdopting a pattern for laterTrả chi phí vận hành ngay, nhận lợi ích có thể không bao giờ đếnYou pay the ops cost now for a benefit that may never arriveQuay lại baseline một máy; đo trước khi thêmGo back to the single-machine baseline; measure before adding

Ba câu cần nhớ

Three things to remember

  1. Phần lớn hệ thống không cần pattern nào cả. Một máy có backup đi rất xa, và mỗi pattern thêm vào là một chế độ hỏng mới bạn phải sống chung.

    Most systems need none of these. One machine with backups goes a long way, and every pattern you add is a new failure mode to live with.

  2. Ba nhóm trả lời ba câu hỏi khác nhau: dữ liệu nằm ở đâu, các dịch vụ chịu lỗi của nhau thế nào, và ai được quyền quyết định khi các node bất đồng.

    The three groups answer three different questions: where data lives, how services survive each other, and who decides when nodes disagree.

  3. Không pattern nào xoá bỏ được đánh đổi. Chúng chỉ dời đánh đổi sang chỗ bạn chịu đựng được. Không nói ra được mình trả giá bằng gì nghĩa là chưa hiểu.

    No pattern removes a trade-off. They only move it somewhere you can tolerate. If you can't say what you're paying, you don't understand it yet.