Part 08 · Self-review · 8.4

Sai lầm và checklist Messaging

Broker không xóa partial failure; nó di chuyển failure window và yêu cầu protocol application rõ hơn.

Phạm vi Part 08: 10 chương · 30 questions · 8 practice labs · 4 execution labs.

05Nhóm red flags
Nhận diện hậu quả production

10Core checklist items
Kiểm tra bằng evidence

04Definition of Done
Xác nhận mức độ hoàn thành

1. Review bằng bằng chứng, không bằng cảm giác

Với mỗi nhận định “đã an toàn”, chỉ ra failure đã gây ra, điều đã quan sát và invariant nghiệp vụ còn được giữ. Các test/gate dưới đây là yêu cầu tự kiểm tra, không phải kết quả chạy sẵn.

Lớp A · Transport evidence

Broker đã nhận, chuyển và theo dõi gì?

Confirm/nack/return, delivery/redelivery, queue state; hoặc topic–partition–offset, position, committed offset, ISR và assignment. Dùng chúng để dựng timeline vận chuyển và recovery. [1] [5] [6]

Chưa đủ để kết luận: DB/payment đã áp dụng đúng một lần. Một event có thể được vận chuyển lại mà business vẫn đúng; cũng có thể transport đã tiến nhưng business bị thiếu.

Lớp B · Business correctness

Trạng thái nghiệp vụ có đúng không?

Đối chiếu tập event ID kỳ vọng với kết quả theo business key, số side effects, state/version và các outcome bị reject hoặc còn pending. Ví dụ invariant của lab: mỗi event hợp lệ tạo đúng một effect; duplicate không tạo thêm effect.

Đừng chỉ so tổng count: thiếu một event và thừa một event khác có thể cho cùng tổng. Cần kiểm từng ID, nội dung/state và thứ tự mà business yêu cầu.

Hợp đồng evidence: mỗi run ghi run ID, code revision, broker/client version, schema, effective config/topology, protocol, workload và time range UTC. Đặt failure trigger có thể lặp lại (barrier/hook thay vì chỉ “sleep rồi kill”), thu dữ liệu trước–trong–sau và ghi expected khác observed ở đâu.
Trạng thái: PASS khi artifact hỗ trợ invariant; FAIL khi quan sát vi phạm; CHƯA ĐO khi thiếu bằng chứng. Không đổi CHƯA ĐO thành PASS vì nhớ lý thuyết.

Phạm vi an toàn: chạy fault injection với dữ liệu giả trong môi trường cô lập, không gọi payment thật và không phá production. Chọn trước ngưỡng latency/processing age, retry budget, RPO/RTO theo workload; sau đó đo. Không có benchmark cố định áp dụng cho mọi máy, broker hoặc cấu hình.

2. Năm nhóm red flags cần phản chứng

Với mỗi nhóm, đi từ hậu quả production tới phép thử phản chứng. Review cả security, vòng đời dữ liệu và khả năng vận hành, không chỉ đường đi happy path.

RF01 · Atomic boundary

Tuyên bố exactly-once cho DB/payment chỉ vì bật Kafka transaction.

Hậu quả production

Payment đã thành công nhưng process chết trước khi hoàn tất Kafka transaction: lần chạy lại có thể thu tiền lần nữa. Một log Kafka “sạch” không phải là bằng chứng rằng ledger bên ngoài chỉ thay đổi một lần.

Kafka transaction có thể gắn output records và consumer offsets trong cùng giao dịch Kafka; consumer cần chế độ đọc phù hợp, như read_committed. Điều đó không tự kéo DB, HTTP API, payment hoặc email vào cùng atomic boundary. [4] [5]

Thiết kế phải bảo vệ điều gì?

Vẽ rõ biên giao dịch. Với DB, dùng dedup/inbox và cập nhật business trong cùng transaction; với payment, giữ nguyên idempotency key và có cách tra cứu outcome chưa rõ. Outbox giải quyết biên DB → publish, không tự bảo đảm mọi side effect ngoài DB.

Ghi rõ thời hạn dedup và replay horizon. Replay sau khi xóa khóa dedup phải có chiến lược an toàn riêng, không chỉ bật lại consumer.

Phép thử phản chứng: cho downstream hoàn tất side effect, rồi chặn phản hồi hoặc kill consumer trước bước hoàn tất Kafka. Dùng cùng event ID khi retry. Nộp trace theo event ID, transaction outcome và reconciliation ledger. Đạt khi không có tác động nghiệp vụ thứ hai; mọi outcome chưa rõ được tra cứu/đối soát thay vì retry mù.

Đối chiếu C01, C07, C08, C09.

RF02 · Timing & retry amplification

Ack/commit trước side effect hoặc retry vô hạn không backoff.

Hậu quả production

Ack/commit trước business commit tạo cửa sổ bỏ sót xử lý khi crash. Đảo thứ tự vẫn còn cửa sổ duplicate: DB đã commit nhưng ack/offset chưa được ghi nhận. Với Kafka, commit vượt qua một record đang xử lý dở còn có thể bỏ qua record đó sau restart. [1] [5]

Retry ngay, không giới hạn, khiến cùng lỗi quay lại liên tục: tăng tải broker/DB, chiếm worker, đẩy message hợp lệ chờ lâu hơn. Lỗi schema hay thiếu quyền không được sửa bằng cách gọi lại nhanh hơn.

Thiết kế phải bảo vệ điều gì?

Hoàn tất side effect hoặc bàn giao bền vững theo protocol đã định trước khi ack/commit; vẫn cần idempotency. Với xử lý song song, chỉ tiến committed frontier qua các record đã nhận và đã xử lý an toàn, không lấy offset lớn nhất vừa hoàn tất.

Phân loại lỗi transient/permanent/unknown; đặt retry budget, backoff có jitter, giới hạn concurrency và điểm chuyển DLQ. Dừng khuếch đại khi downstream không còn khả năng nhận tải.

Phép thử phản chứng: dùng barrier để crash ngay trước và ngay sau business commit; thêm một đợt downstream timeout. Nộp timeline ack/offset, ledger, số attempts theo event ID và đồ thị retry/processing age. Đạt khi không bỏ sót event hợp lệ, duplicate không nhân side effect, retry kết thúc đúng budget và traffic mới vẫn có đường thoát.

Đối chiếu C01, C04, C06, C08, C10.

RF03 · DLQ, lifecycle & ownership

DLQ không owner, không alert, không replay procedure.

Hậu quả production

DLQ trở thành kho lỗi bị quên: yêu cầu nghiệp vụ hết hạn, payload chứa dữ liệu nhạy cảm bị giữ quá lâu, schema cũ không còn đọc được. Replay cả kho sau khi deploy có thể gây duplicate, sai thứ tự và một đợt overload mới.

DLX là một bước publish có thể thất bại. Không được suy ra “đã cấu hình DLX nên không thể mất message”; bảo đảm at-least-once khi dead-letter cần queue type, policy và điều kiện hỗ trợ tương ứng. [2] [3]

Thiết kế phải bảo vệ điều gì?

Mỗi DLQ cần owner, alert theo age/rate, retention, phân loại lỗi, lý do giữ/xóa và replay procedure. Giữ event ID, schema version, nguyên nhân lỗi và lịch sử xử lý; không coi số message trong queue là backlog nghiệp vụ đã được giải quyết.

Replay có người duyệt, quyền riêng, canary, rate limit, stop condition và đối soát sau chạy. Chỉ cấp quyền cần thiết; TLS không thay thế authorization. Payload/log phải được giảm thiểu hoặc che dữ liệu nhạy cảm. [10] [11]

Phép thử phản chứng: gửi poison message, làm đích DLX tạm không sẵn sàng, rồi thử replay payload cũ bằng danh tính có và không có quyền. Nộp policy snapshot, alert đã tới owner, ACL deny log, schema test và replay manifest. Đạt khi message có trạng thái cuối hoặc pending có owner; replay an toàn, không phát sinh side effect trái phép, không có thất thoát âm thầm.

Đối chiếu C04, C09, C10.

RF04 · Ordering scope

Dùng global ordering khi business chỉ cần per-entity.

Hậu quả production

Ép các entity độc lập vào một đường tuần tự tạo head-of-line blocking: một entity chậm giữ cả luồng lại. Nhưng tách partition tùy tiện cũng có thể làm mất thứ tự mà business thực sự cần.

Thứ tự record trong một Kafka partition không đồng nghĩa side effect hoàn tất theo thứ tự nếu worker xử lý song song, retry riêng hoặc ownership đổi khi rebalance. [5]

Thiết kế phải bảo vệ điều gì?

Viết invariant theo aggregate/entity: key, sequence/version và cách xử lý duplicate, gap, stale event. Kiểm tra routing/partitioner khi đổi số partitions; đừng dùng timestamp đơn lẻ để chứng minh ordering.

Nếu thật sự cần global ordering, ghi rõ lý do và chi phí serialization; đây không phải điều cấm tuyệt đối. Nếu chỉ cần per-entity, cho entity độc lập tiến triển nhưng không để retry “nhảy cóc” trạng thái của cùng entity.

Phép thử phản chứng: đưa A1, A2 và B1 vào luồng; làm A1 chậm hoặc phải retry, rồi gây rebalance. Nộp key → partition mapping, sequence trace và lịch sử business state. Đạt khi A không vi phạm thứ tự đã cam kết; B tiến triển trong giới hạn đã đặt. Khi không giữ được ordering, phải chặn/quarantine có lý do, không âm thầm áp dụng sai.

Đối chiếu C01, C06, C09, C10.

RF05 · Skew, capacity & operations

Scale consumer nhưng bỏ qua partitions, hot key và downstream capacity.

Hậu quả production

Thêm consumer không chứng minh được thêm capacity. Trong Kafka consumer group theo partition assignment, số consumer có partition bị giới hạn bởi số partitions; hot key, worker pool và downstream vẫn có thể là nút thắt. Không áp dụng kết luận này nguyên xi cho share groups. [5]

Lag trung bình có thể che một partition rất chậm. Ở RabbitMQ, prefetch lớn cần được đánh giá cùng lượng unacked và khả năng xử lý. Resource alarm có thể chặn publish; retry đồng loạt lúc này làm tình hình xấu hơn. [1] [9]

Thiết kế phải bảo vệ điều gì?

Đo per-partition/per-queue age, key distribution, ingress, processing rate, downstream latency, memory/disk và thời gian catch-up. Thử cả tải lệch key, replay và mất một broker, không chỉ tải đều khi mọi node khỏe.

Đặt backpressure, bounded prefetch/concurrency, quota và headroom dựa trên phép đo. Kiểm tra credential rotation, quyền publish/consume/replay và quản trị; không “sửa” sự cố bằng cách cấp admin đại trà hoặc tắt TLS. [10] [11] [13]

Phép thử phản chứng: tạo hot key, làm DB chậm và giảm tài nguyên broker trong môi trường cô lập; chạy lại cùng workload với TLS/auth và topology thật của lab. Nộp dashboard trước–trong–sau, config diff, alert và reconciliation. Đạt khi hệ thống giới hạn khuếch đại, phục hồi trong mục tiêu đã ghi, không bỏ sót business effect. Không có con số throughput cố định để mặc nhiên “pass”.

Đối chiếu C03, C05, C06, C10.

3. Core checklist · 10 mục

Mở từng mục để xem test, artifact và acceptance gate. Ghi kết quả trong hồ sơ review; việc mở một mục không đồng nghĩa đã hoàn thành.

C01Tôi vẽ được producer–broker–consumer–DB failure windows.

Test / drill cần chỉ ra: Vẽ producer → broker → consumer → DB, đặt điểm crash trước/sau publish, trước/sau business commit và trước/sau ack/offset commit. Với DB → publish, thêm khoảng trống giữa DB commit và việc event thực sự được bàn giao; thử outbox/relay restart.
Evidence / artifact cần nộp: failure-windows.md, trace cùng event ID, commit log đã che dữ liệu nhạy cảm và reconciliation theo tập event ID. Gắn mỗi cửa sổ với một run ID và trigger cụ thể, không chỉ sơ đồ lý thuyết.
Acceptance gate: Chỉ ra được cửa sổ loss, duplicate và unknown outcome; giải thích cơ chế xử lý từng cửa sổ. Ack/offset, business commit và kết quả đối soát phải cùng một lần chạy. Không kết luận an toàn từ việc “process không báo lỗi”.

Red flags liên quan: RF01, RF02, RF04.

C02Tôi phân biệt RabbitMQ confirm với consumer ack.

Test / drill cần chỉ ra: Tạm dừng consumer rồi publish có confirm; sau đó thử routing không khớp với mandatory và xử lý return. Bật lại consumer, crash sau DB commit trước ack rồi quan sát redelivery. Confirm của publisher và ack của consumer độc lập; confirm không tự chứng minh message đã tới đúng queue hay DB. [1]
Evidence / artifact cần nộp: publish-outcomes.jsonl có event ID, confirm/nack/timeout/return; delivery log, queue snapshot và DB ledger. Phân biệt “đã ghi ra socket”, “broker confirm” và “business đã hoàn tất”.
Acceptance gate: Nhận diện được unroutable publish dù có confirm; unknown outcome có cách retry/đối soát với ID ổn định. Chứng minh một publish đã confirm vẫn có thể chưa có business effect khi consumer dừng.

Red flags liên quan: RF01, RF02.

C03Tôi hiểu quorum majority, durability và recovery.

Test / drill cần chỉ ra: Với quorum queue có N thành viên thực tế, majority là floor(N/2) + 1. Ví dụ lab ba thành viên: mất một node rồi mất thêm một node, sau đó phục hồi bằng dữ liệu còn nguyên. Không suy số replica của queue từ tổng node trong cluster. [2]
Evidence / artifact cần nộp: quorum-recovery.md, membership/leader snapshot, tập event ID đã confirm, publish outcome và lịch sử hồi phục. Ghi failure domain, dữ liệu disk có còn không, RPO/RTO đã chọn và thời gian đo được.
Acceptance gate: Phân biệt unavailable do mất majority với mất dữ liệu bền vững. Sau phục hồi, đối soát event đã xác nhận với event còn chờ hoặc đã được áp dụng; không dùng force reset/purge để làm dashboard xanh. Majority không thay backup hay bảo đảm sống sót mọi kiểu mất disk.

Red flags liên quan: RF05.

C04Tôi thiết kế retry/DLX tránh requeue loop.

Test / drill cần chỉ ra: Chạy riêng lỗi transient, lỗi permanent và đích DLX không sẵn sàng. Đặt số attempts tối đa, backoff/jitter và concurrency có giá trị cụ thể trong config của lần chạy. Kiểm tra đường publish-retry → confirm → ack nếu ứng dụng tự chuyển message, không ack nguồn trước khi bàn giao bền vững.
Evidence / artifact cần nộp: retry-policy.json, topology/DLX bindings, attempts theo event ID, thời gian giữa retries, DLQ age, alert và replay manifest. Ghi queue type cùng effective policy, không chỉ file cấu hình mong muốn.
Acceptance gate: Không có vòng requeue nóng; attempts dừng đúng budget; terminal failure đến đúng nơi có owner. Khi đích dead-letter lỗi, chỉ rõ cơ chế giữ/retry hoặc giới hạn loss của thiết kế, rồi kiểm chứng bằng reconciliation. Replay có canary, rate limit và stop condition. [2] [3]

Red flags liên quan: RF02, RF03.

C05Tôi giải thích Kafka log, retention, replication và ISR.

Test / drill cần chỉ ra: Đọc effective config về replication, acks, min.insync.replicas, retention và cleanup policy; làm follower chậm/mất rồi phục hồi. acks=all không có nghĩa mọi replica cấu hình đều đang online. Thử riêng replay khi record đã hết retention hoặc đã compact; offset reset không tái tạo dữ liệu đã bị xóa. [6]
Evidence / artifact cần nộp: kafka-lifecycle.md, leader/ISR snapshots, producer outcomes, log-start/end offsets, tập event kỳ vọng và policy retention. Ghi broker/client version, trạng thái ELR nếu có, election policy và thay đổi topology.
Acceptance gate: Giải thích được vì sao write bị từ chối hoặc được chấp nhận trong cấu hình đang chạy; không đánh đồng ISR với RabbitMQ majority. Chứng minh replay horizon thực tế, tác động time/size/compaction và nguồn recovery khi lịch sử không còn; không coi retention là backup.

Red flags liên quan: RF03, RF05.

C06Tôi phân biệt current/committed position và rebalance.

Test / drill cần chỉ ra: Log current position và committed position riêng: đây là các con trỏ đọc, không phải chứng cứ DB commit. Cho một record chậm trong khi record sau hoàn tất, rồi gây restart/rebalance. Ghi group.protocol; timeout/heartbeat config phụ thuộc protocol và client đang chạy. [5] [7]
Evidence / artifact cần nộp: offset-frontier.csv chứa partition, record offset, business commit, next safe offset và committed offset; kèm assignment/revocation log và các event được xử lý lại.
Acceptance gate: Không commit vượt qua record đã nhận nhưng chưa xử lý an toàn. Ví dụ offset 40 còn dở, 41 đã xong thì không được commit 42 để bỏ qua 40 khi restart. Bảo vệ cả side effect của worker cũ sau khi mất ownership; kiểm duplicate và ordering trong DB, không chỉ đếm rebalance.

Red flags liên quan: RF02, RF04, RF05.

C07Tôi giới hạn exactly-once đúng scope.

Test / drill cần chỉ ra: Viết bảng “nằm trong / nằm ngoài transaction” cho flow đang dùng. Thử abort/restart ở Kafka read–process–write; nếu có DB/payment, đặt lỗi sau external success nhưng trước Kafka completion để phản chứng phạm vi bảo đảm.
Evidence / artifact cần nộp: semantics-boundary.md, transaction/offset logs, consumer isolation config, business ledger và cách xử lý unknown outcome. Với connector/framework, chỉ rõ bảo đảm được tài liệu của chính implementation hỗ trợ.
Acceptance gate: Phân biệt producer idempotence, Kafka transaction và business idempotency. Không tuyên bố end-to-end exactly-once chỉ từ một config; nêu điều kiện, giới hạn retention/dedup và cơ chế reconciliation cho phần nằm ngoài biên. [4]

Red flags liên quan: RF01.

C08Tôi dùng unique constraint cho idempotent consumer.

Test / drill cần chỉ ra: Gửi lại cùng event ID cả tuần tự lẫn đồng thời qua nhiều worker. Đặt unique constraint ở đúng scope, ví dụ (consumer_name, event_id); thao tác ghi dấu đã xử lý và cập nhật business phải commit trong cùng DB transaction. Thử crash trước commit và sau commit trước ack.
Evidence / artifact cần nộp: idempotency.sql (DDL/transaction thực dùng), conflict log và reconciliation.csv theo event ID cùng business key. Nộp trạng thái trước/sau và số business effects, không chỉ số delivery attempts.
Acceptance gate: Event hợp lệ tạo đúng effect theo invariant, event duplicate không tạo effect mới. Không dùng “SELECT chưa có → INSERT” thiếu ràng buộc để chống race; không đánh dấu processed rồi commit riêng trước business. Unique constraint trong DB không tự bảo vệ payment/API ngoài transaction.

Red flags liên quan: RF01, RF02.

C09Tôi kiểm tra schema mixed-version và replay.

Test / drill cần chỉ ra: Lập ma trận writer v1/v2 × reader v1/v2, có thay đổi breaking và thay đổi ngữ nghĩa như đơn vị tiền. Replay dữ liệu cũ theo retention thực tế, kể cả tombstone khi dùng compaction. Test serializer đang dùng; Avro schema resolution chỉ là một trường hợp, không phải mặc định của Kafka. [6] [12]
Evidence / artifact cần nộp: schema-matrix.md, fixture bytes + schema ID/version, kết quả đọc, expected business state và replay-manifest.json. Ghi phạm vi event, người duyệt, rate limit, dedup horizon và kết quả canary.
Acceptance gate: Bản mixed-version được phép triển khai phải có test đạt; bản không tương thích bị chặn hoặc quarantine có lý do. Replay không lặp lại payment/email. Phân biệt replay để hoàn tất side effect với rebuild projection mới: thiết kế namespace/checkpoint phù hợp để dedup không làm projection mới bị rỗng.

Red flags liên quan: RF01, RF03, RF04.

C10Tôi có metrics/runbook cho backlog, lag, DLQ và broker failure.

Test / drill cần chỉ ra: Kích hoạt backlog/lag, DLQ hoặc broker failure trong lab và thực hiện runbook thật: nhận alert → phân loại → giảm khuếch đại → khôi phục → đối soát. Bổ sung negative test quyền publish/consume/replay và rotation credential để review security/operations, không chỉ review happy path.
Evidence / artifact cần nộp: Dashboard export có time range và đơn vị: ingress/processing rate, ready/unacked hoặc per-partition lag, oldest business age, retries, DLQ age, publish latency/error, quorum/ISR, disk/memory và downstream latency. Kèm incident-drill.md, ACL deny log, owner và config diff. Tên metric cụ thể lấy từ exporter/client của lab. [8] [9] [10] [11]
Acceptance gate: Alert tới đúng người; runbook có stop condition, rollback và cách xử lý backlog sau phục hồi. Mục tiêu latency/age, retry budget, RPO/RTO phải đặt trước rồi so với số đo; lag về thấp chưa đủ nếu reconciliation còn thiếu event hoặc thừa side effect.

Red flags liên quan: RF03, RF05.

4. Definition of Done · 4 tiêu chí

Kết luận hoàn thành theo D1–D4. Checklist giúp phát hiện lỗ hổng và ghi việc cần sửa; không dùng tổng điểm tự chấm để che một crash test hoặc recovery drill còn thiếu.

Tách tổng nội dung của Part khỏi ngưỡng tối thiểu để pass.
Tập nội dung	Canonical count	Ngưỡng nguồn / cách tính
8.2 · Questions	30 câu hỏi	Ít nhất 24/30 câu, không mở đáp án.
8.3 · Practice labs	8 practice labs	Ít nhất 6/8 lab thuộc đúng tập 8.3.
8.3A · Execution labs	4 execution labs	Theo dõi riêng số hoàn thành trên 4. Source không đặt ngưỡng pass riêng cho tập này.

D1 · Definition of Done

Trả lời ít nhất 24/30 câu không mở đáp án.

Đánh giá: tự trả lời bộ 30 câu hỏi ở 8.2 trước khi xem đáp án; ghi câu nào đạt, chưa đạt hoặc chưa trả lời. Không dùng số câu đã đọc làm điểm.

Evidence: question-scorecard.md có 30 dòng theo numbering của bộ câu hỏi, bản ghi câu trả lời và phần sửa sau review. Khi chấm, kiểm mental model, failure window, trade-off và evidence được viện dẫn.

Luyện nói bổ sung: hoàn thành riêng bài 8/10 prompt tiếng Anh. Đây là language-practice gate từ Markdown source, không thay thế hoặc làm đổi mẫu số 24/30 câu canonical.

Gate D1: ít nhất 24/30 câu đạt khi không mở đáp án. Đây là ngưỡng nguồn, không đổi thành yêu cầu 30/30.
D2 · Definition of Done

Hoàn thành ít nhất 6/8 lab.

Đánh giá: hoàn tất mục tiêu, failure injection và deliverables của ít nhất sáu lab thuộc 8 practice labs ở 8.3; không chỉ khởi động được broker.

Evidence: practice-scorecard.md liệt kê đủ 8 lab ID thật, trạng thái và đường dẫn run/artifact. Lab chưa có evidence không tính là hoàn thành.

Gate D2: ít nhất 6/8 practice labs. Bốn execution labs của 8.3A là tập riêng; không cộng vào mẫu số 8 hoặc dùng để thay một practice lab chưa hoàn thành.
D3 · Definition of Done

Có một crash test chứng minh duplicate an toàn.

Đánh giá: dùng crash point sau business commit nhưng trước ack/offset completion để chủ động tạo delivery lại. Giữ event ID; kiểm tra cả trường hợp nhiều worker cùng nhận duplicate.

Evidence: crash-duplicate/ có trigger/barrier, timeline trước–sau crash, attempts cùng event ID và reconciliation cho business key. Tên thư mục là gợi ý, không phải artifact có sẵn trong trang này.

Gate D3: ít nhất một crash test thực sự quan sát được xử lý lại, nhưng không nhân side effect và không bỏ sót effect hợp lệ. Chỉ thấy consumer restart mà không có duplicate chưa chứng minh được tiêu chí.
D4 · Definition of Done

Có một overload/rebalance/HA drill với evidence.

Đánh giá: chọn ít nhất một loại: overload, rebalance hoặc HA. Ghi baseline, fault, hành động giảm thiểu, recovery và kiểm tra nghiệp vụ sau hồi phục; không bắt buộc làm cả ba để đạt ngưỡng nguồn.

Evidence: recovery-drill.md, dashboard/alert export, config snapshot, trace và reconciliation. Đặt trước mục tiêu phù hợp workload, như processing age, retry budget, RPO/RTO.

Gate D4: drill có quan sát trước–trong–sau, kết luận đo được so với mục tiêu và tình trạng business sau phục hồi. Không dùng một ảnh “cluster healthy” thay bằng chứng recovery.

Không đổi mẫu số, không tự nâng ngưỡng: tổng là 30 questions, 8 practice labs và 4 execution labs; ngưỡng nguồn vẫn là 24/30 và 6/8. Artifact từ 8.3 hoặc 8.3A có thể dùng cho D3/D4 nếu thực sự đáp ứng tiêu chí. Một run hỗ trợ cả hai phải có evidence riêng cho duplicate safety và recovery; không tự suy ra yêu cầu 4/4 execution labs.

5. Hồ sơ kết luận và việc cần sửa

Người review phải mở được artifact, hiểu workload/fault và tái dựng được kết luận. Lưu bản ghi dưới đây trong kho evidence của bạn; thay null và các map rỗng bằng dữ liệu thật, không dùng chúng như kết quả mặc định.

# MẪU REVIEW — chưa phải kết quả thực nghiệm
review_id: null
reviewer: null
reviewed_at_utc: null
git_revision: null
broker_client_versions: null
group_protocol_if_kafka: null
effective_config_artifact: null
workload_and_fault_artifact: null

canonical_counts:
  questions: 30
  practice_labs: 8
  execution_labs: 4

source_pass_thresholds:
  questions_min: 24
  practice_labs_min: 6
  execution_labs_min: null  # Source không đặt ngưỡng riêng.
  crash_duplicate_tests_min: 1
  overload_or_rebalance_or_ha_drills_min: 1

observed_progress:
  questions_pass: null
  practice_labs_complete: null
  execution_labs_complete: null

# Ghi đủ C01–C10: status, run_id, test, expected, observed,
# transport_artifact, business_artifact, owner, next_action.
core_checklist: {}

# Ghi đủ D1–D4: status và artifact thật.
definition_of_done: {}

# Mỗi vấn đề mở cần owner, hạn xử lý và cách kiểm chứng lại.
open_risks: []

Kết luận cuối: ghi D1–D4 là PASS/FAIL/CHƯA ĐO kèm evidence. Chỉ kết luận đạt Definition of Done khi cả bốn tiêu chí đạt. Các mục C01–C10 còn hở cần owner, hành động và ngày kiểm chứng lại; “đạt ngưỡng học phần” không phải chứng nhận hệ thống đã production-ready.

Tài liệu đối chiếu

RabbitMQ · Consumer Acknowledgements and Publisher ConfirmsConfirm, ack, requeue và unroutable publish.
RabbitMQ · Quorum QueuesMajority, durability, recovery và dead-letter strategy.
RabbitMQ · Dead Letter ExchangesRouting, cycle và giới hạn an toàn khi chuyển DLX.
Apache Kafka · KafkaProducer API (4.3)Idempotent producer và transactional boundary.
Apache Kafka · KafkaConsumer API (4.3)Position, committed offset, group assignment và xử lý song song.
Apache Kafka · Topic Configs (4.3)ISR, retention, compaction và leader-election policy.
Apache Kafka · Consumer Rebalance Protocol (4.3)Phân biệt classic/consumer protocol và cấu hình theo version.
RabbitMQ · MonitoringQuan sát broker, queues, consumers và xu hướng vận hành.
RabbitMQ · Memory and Disk AlarmsResource alarms và publisher backpressure.
RabbitMQ · Authentication, Authorisation, Access ControlAuthentication và quyền trên tài nguyên.
Apache Kafka · Security Overview (4.3)TLS, authentication và authorization là các lớp riêng.
Apache Avro · Specification (1.12.0)Writer/reader schema resolution; chỉ áp dụng khi dùng Avro.
RabbitMQ · Production Deployment GuidelinesCapacity và các điều kiện triển khai production.

1. Review bằng bằng chứng, không bằng cảm giác

Broker đã nhận, chuyển và theo dõi gì?

Trạng thái nghiệp vụ có đúng không?

2. Năm nhóm red flags cần phản chứng

Tuyên bố exactly-once cho DB/payment chỉ vì bật Kafka transaction.

Hậu quả production

Thiết kế phải bảo vệ điều gì?

Ack/commit trước side effect hoặc retry vô hạn không backoff.

Hậu quả production

Thiết kế phải bảo vệ điều gì?

DLQ không owner, không alert, không replay procedure.

Hậu quả production

Thiết kế phải bảo vệ điều gì?

Dùng global ordering khi business chỉ cần per-entity.

Hậu quả production

Thiết kế phải bảo vệ điều gì?

Scale consumer nhưng bỏ qua partitions, hot key và downstream capacity.

Hậu quả production

Thiết kế phải bảo vệ điều gì?

3. Core checklist · 10 mục

4. Definition of Done · 4 tiêu chí

Trả lời ít nhất 24/30 câu không mở đáp án.

Hoàn thành ít nhất 6/8 lab.

Có một crash test chứng minh duplicate an toàn.

Có một overload/rebalance/HA drill với evidence.

5. Hồ sơ kết luận và việc cần sửa

Tài liệu đối chiếu