Độ tin cậy và multi-region

Bài toán

Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.

Diễn tiến theo thời gian

• 2008 · Netflix: DB hỏng dữ liệu, 3 ngày không gửi được DVD. Sự cố này dẫn tới 7 năm lên AWS. Đến 2016 availability tiến gần bốn số 9. Theo Netflix: dựng hệ thống tin cậy từ thành phần không tin cậy nhưng dư thừa, cộng với diễn tập thường xuyên bằng Simian Army. Vẫn có sự cố, như đêm Giáng sinh 2012. Netflix 2016

• 2010 · Twitter: World Cup 2010 làm Twitter liên tục không truy cập được. Họ thiết kế lại theo hướng cô lập lỗi, giảm số máy, thư viện RPC chung. 2013 chịu được đỉnh 143.199 TPS (~25 lần bình thường); gần bốn số 9 trong 6 tháng. Twitter 2013

• 2010→2020 · Meta: phục vụ mỗi phần user từ một region sinh ra bất nhất cache giữa region (thấy thông báo tag ảnh mà chưa thấy ảnh), nên họ xây hệ phân phối invalidation rồi consistency API. Che lỗi bằng Kraken (load test bằng traffic thật), Taiji (cân tải ở edge), Maelstrom (rút traffic khi cả DC gặp thảm hoạ). Meta 2025

• 2011 · Netflix: sự cố AWS US-East (4/2011) là bài kiểm tra lớn đầu tiên của kiến trúc cloud. Thứ đã đúng: service stateless, dữ liệu nhiều bản ở nhiều zone, fail fast/fallback/bỏ tính năng, dư N+1 với 3 zone cùng active, tránh EBS. Thứ chưa đúng: rút khỏi zone phải làm tay qua từng team; ELB cân bằng theo zone trước nên có thể sụp dây chuyền trong một zone. Bài học: Chaos Monkey chưa mô phỏng mất cả AZ (ý tưởng "Chaos Gorilla"), cần tự động failover zone, cần đa region. Netflix 2011

• 2011→2015 · LinkedIn (Espresso): Oracle master/slave cần DBA và downtime để failover sang DC khác; Espresso có Data Replicator (consumer Databus, checkpoint trong ZooKeeper, quản bằng Helix) chuyển commit sang cụm ở DC khác, batch theo partition cho đường WAN. LinkedIn 2015

• 2011 · Airbnb: Theo Airbnb, trả thêm cho dư thừa nhiều AZ là thứ cứu họ khi hai AZ us-east hỏng; coi lỗi AZ là chuyện bình thường phải tự thiết kế để chịu. Airbnb 2011

• 2012 · Instagram: bão Virginia làm sập gần nửa số instance, mất 36 giờ dựng lại. Đến 2015 họ chạy 3 data center:

  • phân biệt dữ liệu global và dữ liệu local;
  • ghi Postgres vẫn về primary;
  • cache theo vùng được invalidate qua replication (PgQ);
  • memcache lease, denormalize counter;
  • sửa việc replica không bắt kịp primary khi latency xuyên vùng 60ms.

  Facebook chủ động tắt một data center để diễn tập. Instagram 2015

• 2012 · Netflix: sự cố ELB đêm Giáng sinh (lỗi control plane cấp region của AWS) cho thấy thiết kế ba AZ không đủ; Netflix nói sẽ làm nhiều region trong 2013 và cảnh báo cách làm ngây thơ có thể kém tin cậy hơn. Netflix 2012

• 2013 · Netflix: active-active us-east-1 + us-west-2: service stateless, tài nguyên trong cùng region, không gọi xuyên region trên đường của user; DNS hai lớp (UltraDNS theo vùng, Route53 để đổi nhanh); Zuul phát hiện request đi nhầm region và đặt trần traffic; Cassandra nhân bản đa region (ghi 1 triệu bản ghi, 500 ms sau đọc được hết ở region kia); deploy theo region với canary, chờ nhiều giờ giữa các region. Diễn tập Split-brain và Chaos Kong (dồn traffic sang một region hơn 24 giờ). Netflix 2013

• 2013→2015 · LinkedIn: từ một data center sang public profile ở hai DC (LA, Chicago) rồi mọi service: replication, callback từ nhiều nguồn, ghim member vào DC gần (Stickyrouting gán DC chính/phụ bằng job Hadoop). TrafficShift (2013) chuyển traffic thật giữa DC khi sự cố và về sau thành công cụ load test hằng ngày. Năm 2015: ba DC chính + PoP. LinkedIn 2015 LinkedIn 2019

• ~2014–2016 · Uber: thêm colocation bờ Đông để DR. Replication vật lý của Postgres tốn băng thông xuyên lục địa, và lưu trữ WAL không theo kịp lúc cao điểm. Đây là một trong các lý do theo Uber để chuyển sang MySQL. Uber 2016

• 2015–2017 · Dropbox: backbone nhắm 99,999%: QoS bốn lớp ưu tiên traffic user; MPLS-TE đẩy traffic nội bộ sang đường dài trước khi thiếu băng thông; tách tầng mạng cho traffic giữa các data center. Dropbox 2017

• 2015 · Riot Games: cụm chat mỗi region 6–12 node tự trị; bảng định tuyến nhân bản đầy đủ trong Mnesia; sau netsplit mỗi node xoá session của node mất liên lạc và tự đồng bộ lại khi nối lại, mỗi node là nguồn chính thức cho dữ liệu của mình. Theo Riot, đạt năm số 9 ở mọi region năm 2015. Riot Games 2015

• 2015 · Algolia: đếm cả DNS là điểm hỏng: API client tự viết dùng hai tên miền, algolia.net (NSONE, đường chính) và algolianet.com (Route53, khi đường chính lỗi), khác cả TLD; không hạ nhà cung cấp chính xuống tập tính năng chung. Algolia 2015

• 2015 · LinkedIn (Kafka): mỗi loại message có cụm local ở từng DC và cụm aggregate gom bằng MirrorMaker chỉ một chiều (không vòng lặp); message qua WAN đúng một lần, consumer luôn đọc local. LinkedIn 2015

• 2016 · Stack Overflow: dư thừa toàn phần trong một data center (rack A/B, nguồn điện, ISP) + data center DR ở Colorado với replica SQL bất đồng bộ. Stack Overflow 2016

• 2016–2018 · Shopify: shard DB năm 2015 làm mất khả năng chịu lỗi (thao tác lặp qua mọi shard). Pod = tập shop trên datastore cô lập, mỗi request chỉ chạm một pod; mỗi pod có một cặp data center, Pod Mover dời một pod sang DR trong khoảng một phút. Shopify 2018

• 2016 · Ele.me: cụm message broadcast dùng chung (chỉ tách bằng virtual host) là blast radius chung: client sai của một nghiệp vụ làm hỏng cả đơn hàng. Họ dựng cụm riêng 7 node. Ele.me 2020

• 2016 · Stack Overflow: mọi máy có ≥2 đường 10 Gbps (LACP) và 2 nguồn điện; DR ở Denver có cùng cấu hình SQL nhưng mỗi cặp ở New York chỉ có 1 máy tương ứng. Stack Overflow 2016

• 2017 · LinkedIn: monolith Voyager-API chạy thành nhiều cụm theo vertical (cùng code), nên một vertical hỏng không kéo sập cả site. LinkedIn 2017

• 2017 · etcd: HA mức region cần tối thiểu 3 thành viên trên 2 AZ, latency thêm thường không đáng kể; nhưng nếu ứng dụng dùng etcd chỉ ở một AZ thì trải etcd qua AZ có thể vô nghĩa. Placement group một AZ giảm latency, đổi lại chịu lỗi kém hơn. etcd 2017

• 2017 · LinkedIn (Waterbear): SRE nhận "độ bền ứng dụng như một dịch vụ": xác định core flow, degrade bằng đổi thời gian (gọi DC khác), đổi độ phức tạp (dữ liệu cache), đổi tính năng (search đơn giản); sửa mặc định degrader của Rest.li (chờ 10 giây mới phạt node chậm, vô dụng với service latency dưới 10 ms) bằng D2Tuner đề xuất cấu hình theo số liệu lịch sử. LinkedIn 2017

• 2018 · Netflix: kiến trúc global cloud (phục vụ user từ bất kỳ region nào) nhân ba lượng dữ liệu cache phải replicate ở mỗi region; EVCache chuyển sang SSD để chịu được chi phí, dùng snapshot để có độ bền khi gặp thảm hoạ. Netflix 2018

• 2019 · Grab: bulkhead ở nhiều mức (AZ, container, process, pool kết nối/luồng) và fallback; Grab còn dựng một backup service sao chép chức năng lõi, theo nguyên tắc phải đơn giản và độc lập hẳn với hệ thống chính. Grab 2019

• 2019 · Atlassian: Tenant Context Service có mặt ở mọi region, client sidecar gọi song song nhiều region và lấy kết quả về trước; chaos trên production (tắt cả region, chèn latency). Một ELB mới chưa kịp scale khi deploy đã làm sập 2 region Mỹ 5 phút. Atlassian 2019

• 2019 · Walmart: DR cho hệ fulfillment microservice theo "Ring": GSLB đổi VIP, Monitor hai tầng ra lệnh failover; client lưu cục bộ và đồng bộ nền nên RTO người dùng thấy gần như tức thì dù quy trình mất vài phút; ghép cặp Ring để bỏ active-passive tốn kém. Walmart 2019

• 2019→2021 · Wix: thành phần cache gọn nên triển khai được ở hơn 15 region mới (2019), rồi chuyển HTML sang CDN để không phải tự vận hành từng region. Wix 2021

• 2019 · Dropbox (cold tier): giữ mỗi region chạy phần mềm độc lập làm tuyến phòng thủ cuối trước bug; đọc gửi ba region và lấy hai phản hồi nhanh nhất, nên mất một region không đổi đường đi của traffic. p99 của cold thấp hơn warm, Dropbox sửa warm sang hedged request. Xoá ở mỗi region chạy phiên bản khác nhau vào lúc khác nhau. Dropbox 2019

• 2019 · Basecamp: Đường chính, đường dự phòng và đường tạm cùng đi qua một nhà cung cấp nên mất cùng lúc; dự phòng kép không chống được sự cố của chính nhà cung cấp. Basecamp 2019

• 2020 · Pinterest: cache tự failover khi server chết hoặc chậm, replicate xuyên AZ cho use case quan trọng (mất một AZ không downtime), tiêm lỗi và latency trên traffic thật. Pinterest 2020

• 2020 · GoCardless: Vault (secret) là phụ thuộc lúc chạy của mọi service, nên chứng chỉ của nó hỏng là cả hệ sập. Sửa bằng cách chỉ nạp secret lúc khởi động container, để mất Vault không giết app đang chạy. GoCardless 2020

• 2020 · eBay: Kafka đa region khi event phải đúng thứ tự: mirror active/active mất thứ tự (compaction, tombstone); ghi toàn cục thì đọc trùng và mất phần chưa mirror; active/passive thì offset consumer lệch giữa cluster; sắp lại theo version thì tốn kém. Theo tác giả, nhiều trường hợp một cluster trải 3 AZ là đủ. eBay 2020

• 2020 · Basecamp: Hai data center với hai đường nối "độc lập" vẫn mất cả hai vì phụ thuộc ẩn giữa nhà mạng; kế hoạch đi lại tuyến cho đa dạng thật và chuyển sang software LB. Basecamp 2020

• 2020 · Asana: Vùng EU cho data residency: domain DB ở châu Âu không mở qua ranh giới vùng, chạy bản sao service tại chỗ; master shard vẫn ở Mỹ qua service mesh xuyên vùng (thêm khoảng 100 ms) nên chép field hay dùng về domain DB; mỗi session chỉ chạm master shard và một domain shard, vi phạm được dò bằng giám sát ẩn trước khi bắt buộc. Asana 2020

• ~2021 · Goldman Sachs: vì quy định, DB quan hệ (RDS Oracle, Aurora) phải chịu được mất region: ứng dụng active/passive, replication bất đồng bộ (chấp nhận mất dữ liệu), công cụ failover tự xây không phụ thuộc region chính hay IaC. CNAME theo region; đồng bộ cả secret giữa region. Theo họ, DynamoDB global table đơn giản hơn nhiều. Goldman Sachs 2021

• 2021 · Yelp: failover giữa hai region chỉ là sửa một file YAML (có duyệt, diễn tập đều); vì từng "làm chảy" region khoẻ, mỗi service luôn chạy đủ container cho 2 lần traffic (dùng khoảng 50%), nên không phải scale lúc khẩn cấp. Yelp 2021

• 2021 · Grammarly: chuẩn bị nhiều region bằng nền tài khoản và mạng: mỗi tài khoản AWS một môi trường của một project, VPC dùng chung khi cần latency thấp, Transit Gateway với route tổng hợp theo khối IP mỗi region thay VPC peering, tạo tài khoản self-service trong khoảng 2 giờ. Grammarly 2021

• 2021 · Alibaba: ba thế hệ DR: cold backup (theo Alibaba, không ai dám chuyển sang) → active-active cùng vùng / ba datacenter hai vùng → multi-active nhiều nơi. Unitization theo user, gắn nhãn request để cả chuỗi gọi ở lại một unit (thay vì đổi DNS), chặn ghi ở đích tới khi dữ liệu bắt kịp; chỉ làm cho nghiệp vụ lõi. Alibaba 2021

• 2021 · Google (InfoQ): theo tác giả, chạy trên cloud nhiều vùng không tự động là cô lập: DB toàn cục dùng chung khiến một lần ra tính năng ở một vùng làm hỏng cả hai. Đặt các thành phần của stack cùng miền lỗi; service stateless dễ cô lập, DB thì đọc cục bộ qua cache và chấp nhận nhất quán chậm. Google 2021

• 2021→2023 · Slack: gray failure một AZ (6/2021) lộ ra người dùng dù có nhiều AZ; thay vì tự phát hiện, làm nút rút traffic khỏi AZ trong 5 phút: silo service theo AZ (chỉ gọi trong AZ, mỗi AZ là một cell), rút bằng trọng số cluster của Envoy ở edge qua RTDS, độ mịn 1%, không phụ thuộc tài nguyên trong AZ bị rút. Slack 2023

• 2021 · WhatsApp: Backup Key Vault (HSM) phân tán theo địa lý ở nhiều data center, vì mất vault là mất khả năng khôi phục sao lưu của mọi user. WhatsApp 2021

• 2022 · Wix: cache trong RAM xuyên region: DynamoDB Global Table lo replication DB, một sync service đẩy CDC (qua Kinesis) thành Kafka để mọi pod ở mọi region cập nhật bản cache; chỉ replication DB thì region khác vẫn đọc giá trị cũ. Wix 2022

• 2022 · Achievers: đa region trên GKE với data residency: chọn Istio (bỏ Kong) để có failover theo locality giữa các cụm, mTLS; sidecar làm lộ vấn đề thứ tự khởi động, ngưỡng HPA lệch, 503 do ứng dụng không xử lý SIGTERM, agent metrics managed bị OOM. Achievers 2022

• 2022 · Twitter: chuyển edge mặc định sang edge cloud công cộng ở vài nước để giảm latency; đo tác động nghiệp vụ bằng phản thực từ các nước không đổi; chiến tranh Ukraine và suy giảm mạng rút ngắn giai đoạn quan sát. Twitter 2022

• 2022 · Uber: chuyển data lake sang active-passive để tiết kiệm (DC chính sinh 90% dữ liệu) biến nhân bản DR thành đường duy nhất: từ 250 TB lên 1 PB mỗi ngày trong một quý, job nhân bản từ 10.000 lên 374.000 mỗi ngày, khó giữ SLO độ trễ P99.9 20 phút. Sửa Distcp (dời listing vào Application Master, song song hoá, chạy job nhỏ trong JVM của AM), thêm circuit breaker khi YARN đầy; năng lực gấp 5 trong một năm, chuyển hơn 306 PB lên cloud (bài 1/2026). Uber 2026

• 2023 · Deno: website công ty và registry package chung một ứng dụng nên DDoS vào website làm hỏng build của cả hệ sinh thái; hướng sửa là tách cách host code module. Deno 2023

• 2023 · Railway: replica của một service trải trên nhiều máy, mạng tự chuyển khi một replica chết; nhưng vẫn giới hạn trong một region, multi-region failover còn là kế hoạch (theo Railway). Railway 2023

• 2023 · Uber (qua lời kể của Onehouse 2024): Hive Sync chép dữ liệu sang region phụ; mất region thì một cụm Presto dự phòng chạy job ưu tiên cao trước, còn lại chạy với SLA giảm. Onehouse 2024

• 2023 · Uber: active-active nhiều region: capacity cho failover lấy từ việc scale xuống workload tier thấp ở region còn lại, failback là hội tụ về trạng thái ổn định đã lưu trong spec của CRD (bài 9/2026). Uber 2026

• 2024 · Fly.io: theo Fly.io, S3 đặt byte ở một region nên user ở xa chịu chậm, càng nặng với request nhỏ và dày; cách quen thuộc là bucket theo region hoặc CDN cache phía trước. Tigris thay bằng storage tự phân phối object tới nơi có nhu cầu, có nhất quán và purge tức thì. Fly.io 2024

• 2024 · Deno: Deno Deploy tách control plane (tài khoản, billing, tạo deployment) khỏi data plane ở các edge region; Postgres giữ thông tin user và project không nằm trên đường request, sập thì không đăng nhập được nhưng deployment vẫn chạy. Code đã xử lý được nhân bản sẵn lên bucket ở nhiều nơi, Anycast đưa request tới region gần nhất. Deno 2024

• 2024 · GitHub: data residency (EU) là một target deploy thêm của cùng code, không phải bản tách nhánh; deploy tới github.com và ghe.com cách nhau vài phút, chỉ merge khi mọi target thành công. GitHub 2024

• 2025 · Cloudflare: lỗi ở control plane (Tenant Service nằm trên đường phân quyền của mọi API) không ảnh hưởng data plane nhờ tách bạch hai tầng. Cloudflare 2025

• 2025 · PlanetScale, Render: cùng sự cố AWS us-east-1, cả hai sống nhờ tách control plane khỏi data plane (static stability) và giữ máy đang có khi không launch được máy mới. Render còn cố ý né us-east-1 cho hạ tầng lõi. PlanetScale: 3 AZ chỉ chịu được mất 1 AZ nếu mạng giữa 2 AZ còn lại ổn. PlanetScale 2025 Render 2025

• 2025 · Notion: đa region vì data residency chứ không vì dự phòng: dữ liệu khách EU không được rời EU. Workspace ID là khoá định tuyến; data lake, search, AI, logging tách theo region; điều phối (Airflow) và config vẫn tập trung. Notion 2026

• 2025 · WarpStream: đa region với RPO=0: data plane ghi quorum 3 bucket ở 3 region (không dùng replication bucket bất đồng bộ, vì 99,99% object mất tới 15 phút); control plane trên DynamoDB Global Tables hoặc Spanner đa region nhất quán mạnh, một leader được bầu theo latency. Mất trọn region leader: latency tăng khoảng 10 giây, không mất record. Giá phải trả: p50 cao hơn khoảng 80–100 ms. WarpStream 2025

• 2025 · Redpanda: cùng sự cố GCP 12/6/2025, theo Redpanda các cluster BYOC không bị ảnh hưởng vì không có metadata hay dịch vụ quan trọng nằm ngoài cluster (cell-based), dữ liệu chính trên NVMe cục bộ; chỉ phần alerting thuê ngoài bị mất thông báo. Redpanda 2025

• 2025 · Alibaba: PolarDB đưa ra bốn mức DR nhiều zone, từ async chỉ storage (phải dựng compute khi chuyển) đến ba node đồng bộ mạnh bằng X-Paxos (RTO dưới 15 giây, không mất dữ liệu); nhiều region dùng GDN đồng bộ redo log, chuyển region bằng tay. Theo Alibaba (nhà cung cấp). Alibaba 2025

• 2025 · Stack Overflow: data center DR ở Colorado ngừng 6/2025 vì không còn cần khi đã lên cloud (multi-zone ở GCP); 2/7/2025 tháo khoảng 50 máy ở New Jersey và tiêu huỷ toàn bộ vì PII. Stack Overflow 2025

• 2026 · Uber: subcluster trong M3DB thu hẹp blast radius của một node hỏng từ gần cả cụm xuống một subcluster, và cho phép bảo trì song song. Uber 2026

• 2026 · Discord: postmortem sự cố voice hơn 3 giờ do một thay đổi cấu hình; một đợt tải lớn "tìm ra" nút thắt mới ở một service cách đó nhiều bước. Họ sửa bằng guard rail khi scale-down, PartitionSupervisor, rate limit, và giám sát mailbox. Discord 2026

• 2026 · Coinbase: co-location trong một placement group vì latency của matching engine là đánh đổi trực tiếp với việc chịu mất AZ. Thiếu failover xuyên AZ đã diễn tập thì mất một toà nhà thành mất cả sàn. Họ cam kết warm standby xuyên AZ và diễn tập failover trên production. Coinbase 2026

• 2010→2026 · Cloudflare: từ một transit provider tới 500 Tbps; phần lớn năng lực là ngân sách DDoS. Chống tấn công tự động trên từng server (XDP/eBPF, luật lan toàn cầu trong vài giây), chặn đợt 31,4 Tbps năm 2025 mà không ai bị gọi dậy. Cloudflare 2026

• 2026 · Atlassian: Kafka managed (MSK) khi một AZ suy giảm thì control plane báo sai và chặn mọi thay đổi đúng lúc cần; họ dựng runbook failover sang cụm sạch dựng từ IaC (khoảng 2 giờ) và companion region trong cùng ranh giới data residency. Atlassian 2026

• 2026 · Railway: mỗi site nối ít nhất ba nhà mạng Tier 1, nhưng một site đời đầu nhận default route từ nhà mạng thay vì tự sinh; ngắt nhà mạng cuối cùng cấp route làm site mất internet 20 phút. Redundancy chỉ đúng khi mọi site cùng thiết kế. Railway 2026

• 2026 · Alibaba (nhà cung cấp): topology triển khai theo mức rủi ro: một DC, hai DC cùng thành phố (mất DC giữ leader thì cần người), ba DC cùng thành phố (tự động), ba DC hai thành phố. Alibaba 2026

• 2026 · Cloudflare: lỗi ký DNSSEC ở TLD .de làm mọi domain bên dưới lỗi với mọi resolver xác thực, bất kể host ở đâu: dependency theo cấp bậc không kiến trúc nào phía dưới tránh được, chỉ giảm tác động (serve stale, NTA, phối hợp giữa các operator). Cloudflare 2026

• 2026 · Redpanda: hai cách chịu mất region cho streaming (theo nhà cung cấp): cụm Raft trải ba region (đồng bộ, RPO = 0, cần đa số còn sống) hoặc hai cụm reciprocal active-passive bằng hai shadow link ngược chiều, tiền tố tên topic theo site. Redpanda 2026 Redpanda 2026

• 2026 · WarpStream: Ripcord Mode cho Agent tiếp tục nhận produce khi Control Plane sập (service discovery chuyển sang object storage, cache ưu tiên availability); đọc, quản lý topic và khởi động Agent mới vẫn chặn. Thử cắt Control Plane một giờ (bài nhà cung cấp). WarpStream 2026

• 2026 · Airbnb: metrics platform có phụ thuộc vòng vào chính hạ tầng nó quan sát; tách sang cluster Kubernetes riêng (vẫn do team Cloud vận hành) và tầng ingress Envoy riêng ngoài service mesh, meta-monitoring khác AZ. Airbnb 2026

• 2026 · Cloudflare: API nội bộ chạy active-active ở Portland và Amsterdam nhưng database chính chỉ ở Portland: RTT khoảng 50 ms giữ kết nối lâu, cạn connection pool, gọi API 10 ms ở Portland nhưng gần 3 giây ở Amsterdam, và đúng một nửa partition Kafka lag. Chuyển sang active-passive, bản active đi theo primary. Cloudflare 2026

• 2026 · Uber: HiveSync giữ dataset chính và bản sao ở vùng khác nhất quán nhờ commit timeline nguyên tử của Hudi; dịch vụ availability nâng bản phụ khi có sự cố, query định tuyến tới vùng gần hoặc khoẻ nhất. Uber 2026

• 2026 · Uber: Consumer Proxy cô lập message theo zone (producer và consumer cùng zone) và theo production/non-production bằng ngữ cảnh trong header, load balancer định tuyến theo header, để sự cố một zone không lan. Uber 2026

• 2026 · Uber: danh mục phụ thuộc fail-close của mọi API quan trọng thành hàng rào chống hồi quy cho Failover Architecture 2.0 và nền cho alert theo phụ thuộc. Uber 2026

• 2026 · Airbnb (metrics storage): tenant theo service với shuffle sharding để một tenant chỉ hạ được vài shard; một cụm cho chắc (guardrail mỗi tenant, tách đường alert khỏi query ad hoc, 3 zone) rồi mới chia nhiều cụm theo workload. Query liên cụm đắt gấp 5–10 lần nên phải gom lại tenant theo mẫu đọc nóng. Airbnb 2026

• 2026 · Meta/WhatsApp: World Cup: không dời tải sang vùng khác như dịp Giao thừa, vì mọi vùng đạt đỉnh cùng lúc nên không có capacity rảnh để mượn; dự báo đỉnh riêng từng vùng thay cho nhân hệ số toàn cầu. Meta 2026

Các lựa chọn và đánh đổi

Quy tắc rút ra

1. Một vùng hoặc một DB duy nhất là rủi ro sống còn khi sản phẩm đã lớn (Netflix 2008, Instagram 2012).
2. Đa vùng làm vỡ các giả định cũ. Cập nhật cache trực tiếp không còn đúng; sửa chỗ này lại đẩy tải sang DB (Instagram).
3. Cách replicate quyết định chi phí xuyên vùng: replication vật lý dài dòng, replication logic gọn (theo Uber).
4. Thiết kế cho đỉnh traffic, không cho mức trung bình (Twitter: ~25 lần).
5. Chỉ diễn tập thật mới chứng minh được (Facebook tắt DC giờ cao điểm; Netflix Simian Army). Nhưng diễn tập chỉ chứng minh thứ nó mô phỏng: Chaos Monkey năm 2011 không giúp gì khi mất cả AZ (Netflix).
6. Cô lập theo ô (cell/pod/subcluster) thu nhỏ blast radius: Shopify pod (theo tenant), Uber subcluster (theo shard), Grab bulkhead (theo thao tác).
7. Quy trình khôi phục bằng tay không scale được (Netflix 2011 rút zone qua từng team; Discord 2026 phải dựng máy bằng tay).
8. Đường dự phòng không chạy thì mục (Cloudflare 2025 không bật lại được backend thứ hai đã gỡ, xem Failover, replica và dự phòng dữ liệu). Đếm cả dependency ngoài hạ tầng: DNS, TLD (Algolia 2015), metadata/control plane ngoài cluster, alerting thuê ngoài (Redpanda 2025).
9. Thành phần nằm trên đường đi của mọi request (Atlassian TCS, Cloudflare Tenant Service) phải được thiết kế khắt khe nhất: cache trên node, gọi song song nhiều region, cấp dư.
10. Hệ quan sát không được chung miền lỗi với hệ nó quan sát (Airbnb 2026); thành phần trung tâm trên đường ghi nên có chế độ giảm cấp cho phép tiếp tục ghi khi nó sập, kèm danh sách rõ cái gì vẫn chết (WarpStream 2026 Ripcord).
11. Nhiều AZ chỉ tăng sẵn sàng khi có cách loại một AZ nhanh: với gray failure, một nút rút traffic do người bấm (silo service theo AZ, đổi trọng số ở edge, tăng dần, đảo ngược được, không phụ thuộc AZ bị rút) đáng tin hơn tự phát hiện. Thao tác bảo trì cố ý bỏ một zone thì biên an toàn bằng 0, phải kiểm trạng thái thật của phần còn lại trước mỗi bước. Slack 2023 Discord 2023

Câu hỏi mở

• Chaos engineering: đã có Netflix 2011 (Netflix 2011), nơi khai sinh ý tưởng "Chaos Gorilla". Đã có active-active 2013 của Netflix (Netflix 2013) với Split-brain và Chaos Kong; Netflix tự nêu phần còn lại là rút ngắn thời gian ra quyết định failover và xử lý dependency chỉ lỗi một phần thời gian. Chưa có số liệu thời gian failover thực tế.
• Postmortem chi tiết: đã có Discord 2026 (Discord 2026). Đã có Netflix đêm Giáng sinh 2012 (Netflix 2012); vẫn thiếu sự cố bão 2012 của Instagram.
• Liên hệ: Scale dọc trước khi scale ngang, Hot partition và thundering herd.
• Liên hệ: Cache và invalidation (lease/single-flight, invalidate giữa region, cache như một dịch vụ).
• Liên hệ: Sự cố và postmortem (giải phẫu các sự cố lớn và bẫy khi khôi phục).
• Liên hệ: Tự động hoá vận hành và auto-remediation (failover tự động, health check, tự sửa: khi automation giúp và khi nó khuếch đại).
• Liên hệ: Failover, replica và dự phòng dữ liệu (cơ chế bên trong một cụm: promote replica, RPO, replication và backup, active-active hay active-passive). Trang này giữ phần kiến trúc nhiều vùng/AZ.