Migration không downtime

Chủ đề Dành cho thành viên
Bài đọc thử: 3/3 (đây là bài miễn phí cuối của bạn) · Xem gói thành viên

Bài toán

Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.

Diễn tiến theo thời gian

  • 2008→2016 · Netflix: 7 năm từ data center lên AWS, xây lại cho cloud chứ không chuyển nguyên trạng. Billing và dữ liệu cá nhân đi sau cùng. Netflix 2016

  • 2010→2012 · Pinterest: từ 1 MySQL tới shard theo ID: denormalize + cache → read slave → chia theo chức năng → shard; feature freeze, ghi kép hệ cũ và mới, "scripting farm" chuyển 500 triệu pin và 1,6 tỉ dòng follower, dự kiến 2 tháng thành 4–5 tháng và phải chạy lại nhiều lần. Pinterest 2013

  • 2011→2013 · Facebook: Unicorn (inverted index nội bộ từ 2009) được mở rộng thành search engine, rồi chuyển mọi backend search cũ (PPS, Typeahead, backend riêng của vài tính năng) sang trước khi ra Graph Search. Meta 2013

  • 2013→2015 · Dropbox: prototype → dark launch (8/2014, mirror giữa hai vùng, giữ backup thêm 6 tháng) → phục vụ in-house (2/2015) → 90% dữ liệu (10/2015), không mất dữ liệu. Dropbox 2016

  • 2013→2017 · Stack Overflow: HTTPS mất 4 năm chuẩn bị (domain meta đổi cấp, Universal Login, dọn mixed content, hơn 1.000 link cứng thành Site.Url()), rồi bật bằng feature flag theo từng site: meta → security → superuser (đo traffic từ Google) → toàn mạng trong 2 tháng; redirect 302 trước, 301 sau. Stack Overflow 2017

  • 2014 · Facebook: kế hoạch bật GTID chính thức đòi tắt cả replica set; họ sửa MySQL để nâng cấp từng replica → promote → nâng cấp primary cũ, chạy trên hàng trăm replica set cùng lúc. Meta 2014

  • 2014→2015 · Allegro: dời khoảng 2.000 thiết bị và khoảng 250 service từ DC2 sang DC5 trong 6 tháng với hạn chót cứng. Giữ redundancy ở mọi bước, 30 chuyến xe, thiết bị tới hôm trước thì hôm sau chạy; tắt mạng DC2 lúc 01:00 ngày 20/4/2015 mà không service nào lỗi. Allegro 2016

  • 2014 · Twilio: Shadow proxy (gửi cùng request tới bản cũ và mới, chỉ trả kết quả bản cũ) chạy khoảng một tháng, cộng account flag để bật dần theo khách. Khi tách shard, hai master tạm sinh ID lẻ/chẵn để không trùng AUTO_INCREMENT. Twilio 2014

  • 2014→2016 · WhatsApp (theo Open Whisper Systems): đưa Signal Protocol vào mọi client theo từng nền tảng và loại tin (Android 1:1 trước). Ba pha: chạy song song có thông báo trạng thái, client không gửi plaintext tới liên hệ đã hỗ trợ E2EE (chặn hạ cấp), rồi cho client cũ hết hạn. WhatsApp 2014 WhatsApp 2016

  • 2014→2015 · LinkedIn: đổi giao thức Rest.li 1.0 → 2.0: server nâng trước, client chọn phiên bản qua handshake trong D2, beta kín ramp bằng A/B rồi bật theo từng nhóm service mỗi tuần. LinkedIn 2015

  • 2015 · GoCardless: schema migration cũng là migration: hàng đợi khoá biến một lệnh nhanh thành 15 giây downtime. GoCardless 2015

  • 2015→2018 · LinkedIn: gộp hai mid-tier search/typeahead về một, theo từng đợt (workflow → typeahead → search). Dùng thư viện parity check so kết quả cũ/mới trước A/B test (95% trùng khớp), ramp 5% member, không sự cố. LinkedIn 2018

  • 2015→2016 · Ele.me: tách monolith Python Zeus qua sáu bước, mỗi bước một tháng: module trong repo chung → proxy ở API cũ + service registry điều khiển lượng traffic → tách repo (git filter-branch) → tách config → deploy riêng. Nửa năm, không sự cố. Ele.me 2020

  • 2015→2016 · Ele.me (shard đơn hàng): order ID mới → ghi kép DB + cache, đọc cũ và so sánh → sửa SQL → đọc mới → chuyển. Trước Tết còn archive chỉ giữ đơn 15 ngày để qua cao điểm. Ele.me 2020

  • 2015 · Vitess (YouTube): resharding đang chạy: dựng shard mới song song, chép snapshot, filtered replication chuyển DML mới tới shard đích, so từng dòng, rồi tắt ghi ở master cũ, chờ master mới bắt kịp, bật ghi; khoảng một giây không ghi được, ứng dụng không biết. Vitess 2015

  • 2015 · Airbnb: chấp nhận downtime có kế hoạch dưới 10 phút của một chức năng để tách DB bằng promote replica: đổi host qua Zookeeper, kill kết nối cũ, chờ replication đuổi kịp rồi promote; bước cuối không đảo ngược được nên dồn công vào chuẩn bị. Airbnb 2015

  • 2015→2017 · Slack (Enterprise Grid): chuyển dữ liệu của từng khách hàng sang mô hình organization: handler idempotent cho từng loại dữ liệu, job queue có pool riêng, dùng lại rate limiter của request bên ngoài cho chính migration, job queue inspector gắn tag theo dõi việc còn lại, bot báo tiến độ mỗi phút cho Sales/CS; migrate team nội bộ trước. Slack 2017

  • 2016 · Grab: shadow traffic: Rails gửi bản sao request + response sang Go để so sánh. Lệnh ghi được mock ở tầng DAO để không ghi đôi. Tăng dần theo RPS chứ không theo %. Đổi DNS sau cùng. Grab 2016

  • 2016 · Discord: đọc/ghi kép MongoDB + Cassandra (dark launch), lộ ra bug eventual consistency; bỏ MongoDB trong một tuần. Discord 2017

  • 2016 · Zomato: feed Redis → Cassandra: ghi kép, hai phiên bản đọc khác nhau; lần đầu ghi chỉ đạt 1.500 lượt/s nên rollback trong vài giờ, sửa (EBS → ổ cục bộ) rồi làm lại; migrate 60 triệu key trong 14 giờ. Zomato 2016

  • 2016→2017 · Slack: đặt Kafka trước hàng đợi job Redis mà không đổi interface của app: ghi kép, relay chạy chế độ bóng (đọc rồi bỏ), đếm job qua từng chặng, heartbeat canary mỗi phút cho 1.600 partition, bật nội bộ rồi bật dần theo loại job. Slack 2017

  • 2016 · Netflix (billing): mảnh cuối rời data center chuyển theo ba hồi, mỗi hồi đổi một biến: nước mới chạy trên cloud và đồng bộ ngược về DC qua SQS + DLQ; chuyển ứng dụng nhưng giữ DB; cuối cùng Oracle → MySQL. Mỗi nước: tắt API ghi của nước đó, chuyển dữ liệu, comparator đối chiếu, bật lại; Mỹ cuối cùng. GoldenGate replication hai chiều để rollback cả sau go-live; luồng signup chuyển sang async để downtime thành trễ xử lý. Netflix tự nhận đánh giá thấp nhu cầu test end-to-end tự động. Netflix 2016 Netflix 2016 Netflix 2016

  • 2016 · Stack Overflow: migrate DB luôn trước code, chạy song song trên hàng trăm DB Q&A; mỗi migration idempotent, có hash để phát hiện file bị sửa; thêm cột dạng nullable trước, ràng buộc sau; không đổi tên object SQL; gần như không rollback mà viết migration mới để sửa. Stack Overflow 2016

  • 2017→2020 · Slack: prototype end-to-end trên một tính năng nhỏ, với backfill + ghi kép + đọc kép có diff. Sau 3 năm đạt 99% traffic; về sau đổi từ migrate từng bảng sang migrate cả shard. Slack 2020

  • 2017 · GoCardless: sau sự cố, dựng cluster mới và chuyển bằng PgBouncer tạm dừng query → promote → chuyển VIP → cho chạy tiếp; tập dượt nhiều tuần. GoCardless 2017

  • 2017 · CapitalOne: rời mainframe từng phần bằng cách chuyển trước phần chiếm khoảng 80% tải là đọc giao dịch: CQRS, mainframe giữ phía ghi, DynamoDB trên cloud giữ mô hình đọc được nạp batch + gần real-time, rồi chuyển traffic từng kênh sang API mới. CapitalOne 2017

  • 2017 · Square: Cutover master bằng MigrateServedFrom sau khi clone + replay binlog; lúc đó không đảo ngược được nếu không mất dữ liệu (Vitess về sau cho đảo ngược). Square 2018

  • 2018 · Slack: tách JSON blob tuỳ chọn workspace sang bảng EAV: ghi kép + backfill → "dark mode" (đọc kép, so sánh, vẫn trả dữ liệu cũ; lộ cả bug có sẵn) → "light mode" bật dần bằng feature flag. Slack 2018

  • 2018→2026 · Etsy: thay tầng sharding tự xây bằng Vitess mà không dời dữ liệu: vindex lai (ID cũ tra SQLite, ID mới dùng hash), chuyển từng bảng theo % traffic; 27 bảng dính transaction phải chuyển cùng lúc. Mất 5 năm, ~2.500 PR. Etsy 2026

  • 2018→2019 · Disney Hotstar: chuyển 40–50 ứng dụng lõi từ EC2 sang Kubernetes giữa hai mùa giải; phải stress test lại từng ứng dụng trong môi trường mới. Disney Hotstar 2020

  • 2018→2024 · trivago: hạ tầng ảnh dời từ data center sang AWS (2018) rồi một phần sang GCP, mỗi lần bắt đầu từ pipeline consumer để khỏi vỡ người dùng DB chung, để lại replication Kafka/Debezium và bảng ánh xạ ID cũ–mới; kết quả là ba môi trường. Lần cuối (2022→2024) thiết kế lại, API schema chốt trước với các team, go-live theo giai đoạn qua A/B test (phải làm nóng cache CDN cho công bằng). Theo trivago, lẽ ra nên chuyển DB trước. trivago 2024

  • 2018→2026 · DuckDB: thay parser kế thừa từ PostgreSQL (YACC/Bison, sửa grammar dễ sinh xung đột) bằng parser PEG, giữ nguyên AST cho binder: prototype nghiên cứu → dùng cho autocomplete CLI (v1.2) → opt-in thử nghiệm (v1.5, lộ backtracking theo hàm mũ với input dị dạng, sửa bằng packrat) → mặc định ở v2.0. DuckDB Labs 2026

  • 2018→2020 · LinkedIn (Lix Engine): thay engine thí nghiệm chạy trong khoảng 500 service: chứng minh tương đương bằng test sinh tự động từ DSL production rồi 8 tỷ test case trên Hadoop (99,9998% nhánh); phát client chứa cả hai engine, chọn bằng A/B test nội bộ để ramp và đo tác động. LinkedIn 2020

  • 2018 · Zillow: chuyển clickstream từ Redshift sang data lake nhưng vẫn chạy song song cả hai vì báo cáo và người dùng còn trên Redshift; có bảng lọc sẵn theo dataset giống giao diện cũ để query dễ chuyển. Zillow 2018

  • 2019→2021 · GitHub: tách ảo bằng linter, rồi dời vật lý bằng hai công cụ độc lập (Vitess và write-cutover tự viết). Cutover chỉ mất vài chục mili giây: read-only → đợi GTID → đổi routing ProxySQL. 130 bảng được dời một lần. GitHub 2021

  • 2019→2022 · Twitter: đưa dữ liệu phân tích từ HDFS lên BigQuery; từ "mỗi team tự làm" chuyển sang một framework tự động. Phần serving vẫn on-prem. Twitter 2022

  • 2019 · Postman: chuyển WebSocket từ Sync sang gateway Bifrost bằng service bootstrap mà mọi client gọi lúc khởi động (Godserver) tăng dần phần traffic: không cần phát hành client mới. Postman 2020

  • 2019→2021 · ASOS: chuyển front-end NodeJS từ Azure Cloud Services sang AKS qua các cổng kiểm tra hiệu năng: test tải đỉnh lộ cạn cổng SNAT (1.024 cổng mỗi node mặc định), SKU hyper-threading, DNS/conntrack race (timeout 5 giây), ndots: 5, thread pool libuv. Sau khi chỉnh, AKS nhanh hơn Cloud Services khoảng 30%. ASOS 2021 ASOS 2021

  • 2019 · Dropbox (Courier): chuyển hàng trăm service sang gRPC: đóng băng tính năng legacy RPC (tracing, streaming chỉ có ở Courier), codegen một interface chung cho cả hai, đổi service sang interface mới trên RPC cũ trước, chạy hai server trong một binary để client đổi bằng diff một dòng, chứng minh hệ cũ không còn dùng rồi mới xoá. Dropbox 2019

  • 2019→2021 · Slack (websocket): HAProxy → Envoy cho hàng triệu websocket: dựng stack Envoy song song (tốn gấp đôi trong lúc chuyển), weighted DNS chuyển theo bậc 10→100% từng region; cấu hình cũ phải giữ cả hành vi vô tình mà code đã dựa vào; thiếu test cho cấu hình load balancer nên phải hỏi từng chủ service. 6 tháng, không ảnh hưởng khách. Slack 2021

  • 2020→2022 · Figma:

    • tách PgBouncer trước, dữ liệu sau;
    • logical replication (bỏ index ở đích để chép nhanh hơn);
    • cutover bằng pause PgBouncer + LSN;
    • replication ngược để rollback.

    Mỗi lần ~30 giây ảnh hưởng một phần (~2% request). Figma 2023

  • 2020→2021 · SoundCloud: chuyển hơn 50 endpoint playlist từ các BFF sang Playlists VAS từng endpoint một, so response cũ/mới; bước này lâu hơn cả viết service mới. SoundCloud 2021

  • 2020 · Notion: ghi kép qua audit log + script catch-up (logical replication không theo kịp), có sẵn audit log ngược để quay về; backfill so version; kiểm chứng bằng dark read, người viết migration và người viết kiểm chứng là hai người khác nhau. Chuyển trong 5 phút bảo trì; theo Notion, thêm một tuần tối ưu catch-up là đã có thể không downtime. Notion 2021

  • 2020 · Reddit: chuyển service lên Kubernetes trong lúc vẫn chạy production: dời từng phụ thuộc một (Ads API → Billing → Serving), gọi thử endpoint từ phía nhận trước khi chuyển, lưu cấu hình cũ để revert. Reddit 2020

  • 2020 · GoCardless: DDL lấy ACCESS EXCLUSIVE, và nếu phải chờ khoá thì mọi query sau xếp hàng sau nó: thêm một cột cũng làm sập app. Sau gem đặt lock/statement timeout thấp, họ viết Nandi, DSL chỉ cho viết migration an toàn và biên dịch ra migration Rails (ví dụ foreign key tách ba bước với NOT VALID), phân tích tĩnh cả migration trước khi chạy; giữ transaction để migration chạy lại được. Gần 600 migration. GoCardless 2020

  • 2020 · Instacart: bật mã hoá at-rest cho RDS Postgres vài TB mà không downtime nhiều giờ: tạo logical slot, snapshot và mã hoá, restore, rồi đẩy vị trí replication khớp LSN của snapshot để replica logic bắt kịp mà không copy lại từ đầu (copy từ đầu mất hơn một tuần); promote nhớ reset sequence. Hơn hai chục replica dựng theo cách này, cả để tạo shard logic. Instacart 2020

  • 2020 · Netflix (Studio): app mới đặt repository (kiến trúc lục giác) giữa logic và nguồn dữ liệu vì monolith sẽ bị tách; khi chạm giới hạn đọc của monolith, đổi việc đọc một entity sang service mới qua GraphQL bằng một dòng cấu hình trong 2 giờ, rollback cũng một dòng. Netflix 2020

  • 2020 · Dropbox: edge proxy Nginx → Envoy: chạy song song hơn nửa năm, chuyển dần bằng DNS theo loại traffic (file, metadata, notification, API, egress); khó nhất là public API vì client phụ thuộc hành vi không theo RFC của Nginx. Dropbox 2020

  • 2020 · Quora: Chuyển bảng sang dạng shard: copy có rate limit → replay binlog → dark read → dark write → copy lại → replay → cutover bằng rename → replay ngược về bảng cũ để có đường lùi. Quora 2020

  • 2020→2022 · Etsy: Cutover sang Vitess bằng MoveTables: staging dựng từ snapshot production làm đi làm lại, VDiff kiểm nhất quán, reverse VReplication làm đường lùi (có alert và runbook khi hỏng vì unique key chỉ duy nhất trong từng shard), --no_scatter để scatter vô tình chỉ làm một query lỗi. Không downtime. Etsy 2023 Etsy 2023

  • 2021→2022 · Stack Overflow: kế hoạch chỉ đưa tier Business lên Azure thất bại sau ~1 năm (chia một sản phẩm ra hai nơi phá đăng nhập và tích hợp). Kế hoạch mới gồm 5 pha. Pha 1 thêm một site cha mới để biến bước big-bang thành nhiều bước nhỏ đảo ngược được, dời team nội bộ trước. Stack Overflow 2023

  • 2021 · Zalando: parallel run: monolith trả lời user trước, rồi gửi bất đồng bộ bản sao request/response sang service mới để so sánh; mỗi endpoint có ngưỡng nhất quán riêng; chuyển từng endpoint qua proxy Skipper. Chỉ dùng được cho endpoint idempotent; GDPR làm khó việc điều tra chỗ lệch. Zalando 2021

  • 2021 · Quora: ghi kép → backfill INSERT IGNORE → shadow read 5% → cắt (vẫn ghi kép để quay lại được) → giữ HBase thêm 6 tháng cho bảng đầu tiên. Quora 2021

  • 2021 · Wix: ba cách theo thuộc tính dữ liệu: theo vòng đời (dữ liệu có TTL thì ghi kép rồi chờ hết một vòng đời), lặp toàn bộ (bỏ vì không biết tiến độ, clone thiếu dữ liệu), tăng dần theo entity (bảng trạng thái migrate cho từng phòng chat). Wix 2021

  • 2021 · CapitalOne: Postgres → DynamoDB bằng chế độ hai database: đọc/ghi cả hai, chỉ trả dữ liệu Postgres cho user; chạy production vài tuần không lỗi rồi tắt Postgres. CapitalOne 2021

  • 2021→2022 · Mercari: chuyển monolith PHP Mercari API từ GCE sang GKE từng thành phần, traffic 1% → 5% → 10% → 50% → 100% (12/2021–2/2022). Lỗi lớn nhất theo chu kỳ giờ: CronJob của service khác restart pod mỗi giờ, node scale out chạm giới hạn số VM trên một backend của GCLB; sửa bằng GKE subsetting. Mercari 2022

  • 2021→2025 · etcd: membership ghi ở hai kho, v2store là nguồn sự thật ở v3.5, v3store ở v3.6. Bug từ v3.5.1 chỉ ghi promote learner vào v2store; lỗi ngủ yên tới khi nâng v3.6 thì voter thành learner, nâng cấp hỏng. Bản sửa đầu (v3.5.20) sót trường hợp learner mới nhận snapshot sai từ máy cũ khi thay dần từng máy; phải lên v3.5.24 trước. etcd (CNCF) 2025

  • 2021→2022 · Shopify: đổi định dạng cache đang dùng: ghi MessagePack có tiền tố phiên bản, đọc cả hai, fallback về Marshal khi chưa hỗ trợ và log từng lần, tới khi log về 0 mới bỏ Marshal (khoảng 6 tháng). Shopify 2022

  • 2021→2026 · Airbnb: migration observability nhiều nghìn khách nội bộ: v1 chọn service khó nhất làm đầu tiên và cố giữ y hệt hành vi cũ thì sa lầy; v2 chọn service gần hệ đích, làm công cụ dịch dashboard/alert, dịch ý định thay vì dịch từng chữ, bỏ shim ngôn ngữ cũ sau khi xong. Theo Airbnb, dịch mù pattern sai là chuyển nợ sang hệ mới. Airbnb 2026

  • 2021 · Alibaba: chuyển khám phá service của Dubbo từ theo interface sang theo ứng dụng mà không đổi code nghiệp vụ: metadata center giữ ánh xạ interface → ứng dụng và snapshot metadata theo mỗi lần release, nên client cũ và mới cùng chạy, client tự quyết khi nào bật chế độ mới. Alibaba 2021

  • 2022 · Monzo: migrate hơn 2.000 service sang Argo Rollouts bằng một migrator service chạy theo lô (ít quan trọng trước), có hàng đợi và revert; theo Monzo, giao cho từng team tự migrate thì "bị treo vô thời hạn". Monzo 2022

  • 2022 · Discord: Cassandra → ScyllaDB cho hàng nghìn tỷ tin. Data service đặt ở giữa trước; ghi kép; migrator Rust (đọc theo token range, checkpoint bằng SQLite, 3,2 triệu tin/giây) rút 3 tháng xuống 9 ngày, nhờ vậy bỏ được phương án cắt theo mốc thời gian. Kẹt ở 99,9999% vì tombstone chưa compact. Kiểm chứng bằng cách đọc một phần nhỏ từ cả hai DB rồi so sánh. Discord 2023

  • 2022→2024 · Cloudflare: dời 1,7 tỷ + 4,3 tỷ record DNS khỏi cfdb: trước hết chuyển hơn 20 service sang một gRPC API; CDC bằng trigger + lô + audit số lượng hai đầu; cutover dưới 2 giây nhờ API giữ request HTTP lại; foreign table làm lối thoát. Cloudflare 2024

  • 2022 · Vitess: cut-over của online DDL (bước nguy hiểm nhất): đệm query bằng ACL có hạn 10 giây ở proxy → chờ 100 ms → RENAME bảng gốc đi (ghi trở nên bất khả) → bắt kịp binlog tới gtid_executed → đổi tên bảng mới vào → gỡ đệm. Bước nào cũng quay lui được; ghi audit trước khi đổi tên để process khác khôi phục nếu mình chết giữa chừng. Vitess (PlanetScale/CNCF) 2022

  • 2022 · Yelp: dời Kafka từ EC2 sang Kubernetes: thêm hai đường vào cụm, gấp đôi số broker rồi dùng API remove_broker của Cruise Control dời partition khỏi từng broker cũ; tắt mọi tự động rebalance tranh nhau trong lúc đó; darklaunch trên cụm clone bằng MirrorMaker trước. Yelp 2022

  • 2022 · Alibaba: hơn 2.000 ứng dụng, 400.000 node thương mại điện tử chuyển từ HSF sang Dubbo3 trước Double 11; Ele.me thay hệ microservice tự xây (2.000 ứng dụng); service discovery theo ứng dụng giảm 90% dữ liệu registry (theo Alibaba). Alibaba 2023

  • 2023 · Figma: shard logic bằng view (rollback chỉ là đổi config), shadow reads, rồi failover vật lý 1 → N; 10 giây ảnh hưởng một phần. Họ cố ý không ghi kép để giữ nhất quán. Figma 2024

  • 2023→2025 · Uber: đổi kiến trúc CPU cho 5.000+ service là migration xuyên mọi tầng: host image, công cụ build Makisu (không cross-compile), CI, nền tảng stateful Odin đều giả định x86, có phụ thuộc vòng phải gỡ từ đáy lên bằng Bazel. Ảnh đa kiến trúc cho cùng một tag chạy trên cả hai loại máy, nên chuyển dần được; monorepo trước, micro-repo sau; CI chạy test trên cả hai kiến trúc (bắt lỗi dấu phẩy động). Uber 2025 Uber 2025

  • 2023 · Slack: chuyển khoảng 60.000 EC2 ở 17 region, hàng trăm account, sang IMDSv2: đo ai còn gọi v1 (metric CloudWatch theo instance, rồi công cụ tìm process), sửa code cùng team, tắt v1 trong module Terraform dùng chung với danh sách account ngoại lệ co dần, chặn bằng Service Control Policy cùng danh sách đó, cuối cùng phát hiện qua EventBridge và tự ép v2. Slack 2023

  • 2023→2026 · Yelp: apollo-tooling bị khai tử (4/2023); thay bằng GraphQL Codegen cấu hình để sinh output giống hệt (cùng đường dẫn, cùng tên kiểu), nên developer không đổi dòng nào; chuyển từng lô package theo một danh sách co dần, có thể thêm lại package lỗi. Yelp 2026

  • 2023 · Notion: cutover từng shard bằng script: tạm dừng traffic ở PgBouncer, chờ replication đuổi kịp, đổi mapping, thu quyền vào DB cũ và đảo chiều replication (DB mới sao chép ngược về DB cũ) làm đường lùi, mở lại traffic; tệ nhất user thấy một giây "đang lưu". Trước đó dark read trên mẫu nhỏ (chỉ query trả tối đa 5 dòng để không thêm CPU vào đường nóng). Notion 2023

  • 2023 · Stripe: cutover của migrate chunk đặt ngưỡng bằng một lần failover có kế hoạch (vài giây, trong ngân sách retry của app): tăng version token trên shard nguồn để từ chối đọc/ghi, chờ replication, đổi route; request lỗi thành công khi retry. Replication hai chiều giữ đường lùi. Stripe 2024

  • 2023 · Stack Overflow: Teams lên Azure pha 2–5: kịch bản 27 bước tách hạ tầng được tập dượt trên dev (lỗi tiền tố key Redis chỉ lộ khi tập), cắt chuyển 11/3/2023; lift-and-shift sang bản sao chỉ đọc trên Azure rồi mới đổi primary; tổng cộng gần hai năm. Stack Overflow 2023

  • 2024 · Grab: chuyển xử lý 16 Kafka stream sang service mới, không mất không trùng dữ liệu: loại feature flag (cập nhật lệch giờ giữa hai service), chọn mốc thời gian chuyển nằm trong code dùng chung (monorepo); kiểm chứng bằng "sink" tạm. Hạn chế tự nêu: rollback sẽ gây sai lệch. Grab 2024

  • 2024→2025 · Uber: chuyển hàng nghìn phiên notebook tương tác từ Peloton (Mesos) sang Kubernetes. Restart là bắt buộc, nên họ giữ đúng thứ user đau khi mất: danh sách package đã cài (theo dõi bằng inotify, cài lại khi khởi động), thay vì checkpoint cả container. Uber 2025

  • 2024 · Neon (nhà cung cấp): khi mỗi khách chạy một phiên bản schema, tuyến tính hoá đường nâng cấp và viết migration idempotent để bản vá backport không làm hỏng lần nâng cấp sau. Neon 2024

  • 2024 · Allegro: migrate code trên hơn 2.000 repo bằng PR tự động (Dependabot + OpenRewrite), audit và đảo ngược được, hạn chót + force-merge cho phần đuôi. Allegro 2024

  • 2024 · Slack: bỏ SSH khỏi hơn 700 job pipeline trên 8 region: migrate theo từng loại operator, dev → GovDev/CommDev → prod, dashboard "còn bao nhiêu" bằng query DB của Airflow, chặn operator cũ ở cuối; đường mới lộ ra giới hạn vmem và phụ thuộc mạng mà SSH từng che. Slack 2026

  • 2024 · Kubernetes: kubectl exec/attach/cp/port-forward đổi từ SPDY (bỏ 8 năm, không chuẩn hoá, proxy hiện đại không hỗ trợ) sang WebSocket. Chuyển qua ba bản: feature gate phía server từ v1.29–1.30, biến môi trường phía client, thương lượng subprotocol; tới v1.31 mới bật mặc định. Kubernetes (CNCF) 2024

  • 2024 · Slack: EMR 5/Spark 2 → EMR 6/Spark 3 cho hơn 40 team trong một năm: nâng Hive Metastore lên bản tương thích ngược để hai thế hệ cụm dùng chung catalog, Bazel dựng JAR cho cả hai phiên bản, một cờ trong operator Airflow chuyển từng job, thu dần fleet cũ theo mức dùng; so khớp chính xác toàn bộ dữ liệu billing thay vì lấy mẫu, liệt kê sẵn nguồn lệch không phải lỗi (timestamp, thứ tự khi hoà, NULL). Không có sự cố. Slack 2024

  • 2024→2025 · Mercari: tài khoản người dùng ngoài Nhật không đưa vào hệ cũ: ghi vào service mới, reconciler đồng bộ ngược sang DB của monolith PHP cho các dịch vụ chưa chuyển. Mercari 2025

  • 2025 · Shopify: reservation từ Redis sang MySQL: "shadow mode" ghi kép, Redis vẫn là nguồn sự thật; chuyển nguồn sự thật khi đã chắc; còn kill switch để quay về; rollout từng pod, từ ít traffic tới khách lớn nhất. Shopify 2026

  • 2025→2026 · Zalando: join stream quảng cáo tự viết → Flink: shadow pipeline đầy đủ 4 tuần (tỷ lệ làm giàu event khớp 99,9%, số theo campaign, latency, trùng khoảng 0,2%), rồi A/B một tuần theo kết quả campaign, chuyển bằng một thay đổi config. Zalando 2026

  • 2025 · Cloudflare: thêm backend thứ hai cho Workers KV: ghi nền sang backend mới → copy dữ liệu (từ đây failover tay được trong vài phút) → bật active-active cho namespace nội bộ trước, so sánh hai backend sau khi đã trả response; rollback tạm khi phát hiện hồi quy read-your-own-write. Cloudflare 2025

  • 2025 · Zig: chuyển git hosting từ GitHub sang Codeberg vì CI (Actions) tắc: repo cũ read-only, không migrate issue (giữ ở GitHub như "copy-on-write"), issue mới đánh số từ 30000 để không trùng. Zig Software Foundation 2025

  • 2025 · ClickHouse: (nhà cung cấp) migrate từ TimescaleDB bằng CDC giữ hai kho đồng bộ với độ trễ vài giây, dời đọc trước, dời ghi sau. ClickHouse 2025

  • 2025 · WarpStream: Schema Linking chép liên tục schema registry kiểu Confluent sang registry của WarpStream bằng vòng reconcile (mong muốn = subject version của nguồn, hiện tại = của đích, so hai mảng, chép phần thiếu), giữ nguyên schema ID nên client không phải đổi; chạy tiếp thì thành read replica hay bản DR. Theo WarpStream. WarpStream 2025

  • 2025 · Spotify: migration của consumer khi khai tử dataset (khoảng 1.800 pipeline): lineage để tìm phạm vi, PR tự động theo bảng ánh xạ, chỗ cần phán đoán thì để nguyên kèm comment; phần không chuẩn hoá (Scio) và không có test thì tự động hoá không với tới. Spotify 2026

  • 2025 · LinkedIn (qua ClickHouse): ba hệ metadata metric thay bằng một bảng ClickHouse mà không client nào phải đổi, vì mọi công cụ vốn đi qua một gateway; gateway chuyển sang viết SQL. Bảng dựng lại mỗi ngày, bắt kịp bằng CDC, đổi alias rồi xoá bảng cũ. ClickHouse 2026

  • 2025 · Stack Overflow: Ingress-NGINX bị khai tử (11/2025) buộc chuyển sang Gateway API; dựng test từ Ingress object của production, đo cả thời gian hội tụ 5.000 route và gai latency khi sửa route dưới tải; chọn Istio. Tích hợp phức tạp (auth) khác nhau giữa các bản là phần tốn thời gian nhất. Stack Overflow 2026

  • 2025 · Mercari: nhập sản phẩm của shop B2C vào hệ toàn cầu theo bậc: một shop, index nhưng ẩn khỏi kết quả, bật cho nội bộ qua feature flag, rồi thêm shop qua whitelist; backfill chạy giờ thấp điểm từ shop nhỏ tới lớn với RPS theo capacity của service phụ thuộc. Migrate đơn hàng từ hệ cũ: live sync và backfill dùng chung một luồng upsert idempotent đọc từ nguồn sự thật. Mercari 2025 Mercari 2025

  • 2025 · Stack Overflow: site public rời data center sang GCP trước hạn cứng 31/7/2025: đội chuyên trách, mốc nội bộ không công bố, chuyển từng service nhỏ nhất trước; app đổi từ mỗi site một database Redis sang tiền tố key để dùng được Memorystore. Stack Overflow 2025

  • 2025 · Stack Overflow: khép lại việc chuyển: data center New Jersey đóng cửa là hạn chót cứng; sau ngày 2/7/2025 Stack Overflow không còn máy chủ vật lý nào. Stack Overflow 2025

  • 2026 · Meta: chuyển hàng chục nghìn job ingestion (vài PB/ngày, CDC) sang hệ mới qua shadow → reverse shadow (đảo vai để vẫn so được và rollback ngay) → dọn dẹp. Mỗi giai đoạn có tiêu chí (checksum, landing latency, tài nguyên), công cụ tự thăng/hạ giai đoạn. Partition lỗi được đánh dấu để chặn lỗi lan truyền. Meta 2026

  • 2026 · Trigger.dev: nâng cấp cụm Aurora 56 TB (tăng 250 GB/ngày) mà không dời dữ liệu nguội: run mới sang DB mới (định tuyến theo định dạng ID), chỉ chép 1,23 TB control plane. Thu quyền ghi của DB cũ để tìm đường ghi bị quên. Cutover qua PgBouncer với finally quay về: lần 1 thất bại (kết nối cũ giữ username cũ), tự rollback sau 105 giây; lần 2 thành công. Trigger.dev 2026

  • 2026 · LINE: mã hoá đầu-cuối cho topic Kafka tới 1 triệu message/giây: consumer hiểu cả message có và không có header mã hoá được deploy trước, rồi producer bật mã hoá theo tỉ lệ 1% → 100% trong hai tuần; xoay khoá bằng giai đoạn header chứa cả khoá cũ và mới. LINE (LY Corp) 2026

  • 2026 · GitHub: search HA của GitHub Enterprise Server chuyển từ một cụm Elasticsearch trải qua primary và replica sang các cụm một node nối bằng Cross Cluster Replication; migration tự chạy khi khởi động lại, là tuỳ chọn từ bản 3.19.1 và sẽ thành mặc định trong hai năm. GitHub 2026

  • 2026 · Atlassian: AOSC (plugin OpenSearch) đổi số shard và mapping của index đang phục vụ: backfill + phát lại changes snapshot của Lucene (giữ bằng retention lease) tới khi khoảng cách dưới 500 thao tác, chặn ghi 2–5 giây (tối đa 30 giây với index 50 TB), so số document, đổi alias. Trước bước đổi alias mọi thứ huỷ được. Atlassian 2026

  • 2026 · Upstash: log từ SQLite sang Elasticsearch bằng ghi kép nhiều tuần cho tới khi hệ mới có đủ lịch sử bằng cửa sổ retention, rồi mới chuyển đọc dần, giữ hệ cũ làm dự phòng. Upstash 2026

  • 2026 · LINE (LY Corp): ba cách migrate cùng loại DBMS sang Flava: dump & restore (downtime), replication rồi failover (đổi endpoint), CDC qua Kafka (đổi được topo, ví dụ Redis 6 → 3 shard); công cụ DMB cho developer tự migrate MySQL. LINE (LY Corp) 2026

  • 2026 · Coinbase: hơn 300 namespace Temporal sang Temporal Cloud; workflow đang chạy gắn với cụm giữ lịch sử nên không đổi endpoint được. Hai cách: drain and switch khi được dừng tạo mới; dual workers (worker poll cả hai cụm, định tuyến lúc start theo % bằng băm tất định, rollback là hạ %) cho trading và workflow dài. Qua một pha trung gian tự vận hành trước khi lên vendor. Coinbase 2026

  • 2026 · WarpStream: chuyển producer Kafka không downtime: producer đổi bootstrap URL trước, Agent làm proxy chuyển tiếp về cụm cũ; cutover theo từng topic bằng máy trạng thái (vài giây, tự quay lui nếu quá hạn). Giai đoạn proxy giả lập latency và auth của hệ mới để lỗi lộ sớm; lease vài giây để Agent bị cô lập không ghi nhầm; chấp nhận trùng lặp thay vì mất dữ liệu. Theo WarpStream (nhà cung cấp). WarpStream 2026

  • 2026 · Grab: data lake từ Hive Parquet (metastore thành điểm nghẽn, file nhỏ, không ACID) sang Apache Iceberg từng bảng, bảng giá trị cao trước, ưu tiên theo tần suất scan và chi phí API vì sinh metadata gây spike chi phí một lần. UnifiedSparkCatalog chuyển hướng thao tác tới đúng catalog theo định dạng, để truy vấn hạ nguồn không vỡ khi bảng đổi định dạng. Grab 2026

  • 2026 · Kubernetes: đổi storage version của một resource chỉ áp dụng cho lần ghi mới; object cũ nằm im ở dạng cũ (hoặc chưa mã hoá sau khi bật mã hoá) cho tới khi được ghi lại. API StorageVersionMigration (GA ở v1.37) để controller tự ghi lại toàn bộ, có status theo dõi; chỉ gỡ version cũ khi .status.storedVersions đã sạch. Kubernetes 2026

  • 2026 · Kubernetes: viết lại kpromo (công cụ promote image mà mọi bản phát hành phụ thuộc) qua chín pha, giữ nguyên lệnh, flag, manifest: bật engine mới làm mặc định ở một release, cho chạy production, rồi mới xoá code cũ ở release sau để luôn có đường lui. Code nhỏ đi 20%; hai regression bắt được sớm, sửa trong vài giờ. Kubernetes 2026

  • 2026 · Redis: atomic slot migration: chép snapshot của slot + luồng delta qua hai kết nối, khi delta xuống dưới ngưỡng thì tạm dừng ghi một chút, đẩy nốt, chuyển quyền một lần; client chỉ thấy -MOVED sau khi xong, không còn trạng thái nửa slot ở nguồn nửa ở đích. Slot cũ xoá ở thread nền. Redis 2026

  • 2026 · Prometheus: muốn bỏ dạng lưu histogram cổ điển mà không đợi mọi query, dashboard, hệ nhận remote write chuyển: thêm lớp dịch ngược lúc đọc (mẫu phức hợp trải ra dạng cổ điển cho foo_bucket ... by (le)), để đổi bên ghi trước, bên đọc sau. Chuyển chiều trải ra thì dễ, chiều gộp lại thì gần như không làm được với dữ liệu đẩy tới. Prometheus 2026

  • 2026 · Slack: đổi nghĩa preference thông báo của hàng triệu user mà không ghi đè dữ liệu cũ: thêm trường mới desktop_push_enabled rồi backfill, diễn giải "off" cũ thành "mentions + tắt push" lúc đọc; rollback chỉ là đổi code. Một trường sai định dạng làm reset preference cho tới khi xả memcache. Slack 2026

  • 2026 · Yelp: đổi bundler Webpack → Rspack mà không có PR sống lâu: chọn công cụ tương thích cấu hình, cấu hình adapter giữ nguyên bản gốc và hiện rõ phần khác, developer tự bật theo trang, kiểm bằng deployment preview, rồi mới đổi mặc định. Yelp 2026

  • 2026 · Cloudflare: chuyển control plane Workflows sang V2 với hàng triệu instance đang chạy: request tạo mới đi vào SousChef mới, DO Account cũ tự biến thành một SousChef (giữ metadata), DO cũ tắt dần khi hết hạn giữ instance. Cloudflare 2026

  • 2026 · Railway: bỏ Next.js trên hơn 200 route bằng hai PR: PR 1 gỡ mọi phụ thuộc riêng của framework mà không đổi framework, PR 2 mới đổi; merge sáng Chủ nhật, cả team dùng thử ngay. Railway 2026

  • 2026 · Stripe: dựng harness replay khi migrate: tách lõi quyết định khỏi điều phối, Spark chạy bản cũ và bản mới trên traffic lịch sử, diff ghi đường luật đã đi. Theo Stripe, migration là lúc rẻ nhất để vạch lại ranh giới, và harness giảm rủi ro cho chính migration đó. Stripe 2026

  • 2026 · Istio: rời GCP sang AWS; image, Helm chart, artifact có địa chỉ mới song song, khoá ký mới từ 1.31.1 kèm bảng phiên bản → khoá. Vì không biết hết ai còn kéo từ địa chỉ cũ, họ chạy scream test: tắt địa chỉ cũ theo lịch công bố, dài dần 1 → 3 → 6 → 24 giờ, trước khi xoá hẳn tháng 12. Istio (CNCF) 2026

  • 2026 · Doximity: đổi framework UI của màn hình dùng nhiều nhất mà không có cutover: chuyển lá trước bên trong khung cũ, rồi đảo chiều cầu nối để khung mới chứa phần cũ còn lại; rollout theo phần trăm người dùng có đường lùi; xong khi giàn giáo cũ hết việc. Doximity 2026

  • 2026 · Uber: tách database Hive nguyên khối (16.000 dataset, 10 PB) thành database theo domain bằng cách copy một lần rồi đổi con trỏ vị trí trong Hive Metastore; dataset backup là một con trỏ để rollback; kiểm checksum và chất lượng mọi partition trước khi lật; đồng bộ metadata hai chiều bằng Flink cộng một lưới đỡ batch mỗi 2 giờ; hơn 7 triệu lượt đồng bộ. Uber 2026

  • 2026 · Airbnb: nâng MySQL 5.7 → 8.0 cả fleet bằng capture ở ProxySQL và replay traffic thật lên DB đích, có chế độ chạy cùng lúc hai đích để so kết quả: lộ query chậm từ 0,03 lên 2,6 giây, ID auto-increment không còn tuần tự, query không có thứ tự xác định trả dòng khác khi có LIMIT. Làm cụm rủi ro nhất trước, không có sự cố production lớn. Airbnb 2026

  • 2026 · WhatsApp: thay thư viện media C++ bằng bản Rust viết song song (không thay dần), kiểm tương đương bằng differential fuzzing rồi rollout cho mọi nền tảng. WhatsApp 2026

Các kỹ thuật và đánh đổi

Kỹ thuật Ví dụ Bắt được gì Cái giá
Shadow traffic + so sánh Grab, GitHub (Scientist), Figma (shadow reads) Sai logic, sai hiệu năng Lệnh ghi cần cơ chế riêng; lệch do trạng thái thay đổi
Ghi kép + đọc kép có diff Discord 2016/2022, Slack Sai ngữ nghĩa giữa hai kho Khó giữ nhất quán; Figma tránh dùng
Replication rồi cutover ngắn GitHub (GTID), Figma (LSN) Mất dữ liệu (kiểm tra vị trí log) Vài giây ảnh hưởng ghi
Lớp trung gian để đổi routing PgBouncer, ProxySQL, VTGate, DBProxy, data service Lỗi routing trước khi dời dữ liệu Thêm một thành phần
Rollback được thiết kế sẵn Figma (replication ngược, view), Dropbox (backup 6 tháng) Ẩn số chưa biết Tốn thêm tài nguyên
Reverse shadow (đảo vai cũ/mới sau rollout) Meta 2026 (Meta 2026) Lệch phát sinh sau khi đã cắt Chạy hai hệ thêm một thời gian
Parity check tự động trước A/B LinkedIn 2018 (LinkedIn 2018), SoundCloud (so response từng endpoint) Sai kết quả nghiệp vụ Cần phân loại lệch "chấp nhận được"

Quy tắc rút ra

  1. Kiểm chứng bằng traffic thật trước khi chuyển: shadow, đọc kép, so sánh tự động.
  2. Gỡ phụ thuộc logic trước khi dời vật lý (GitHub, Figma). Xem Sharding và tách database.
  3. Chèn một lớp trung gian để đổi phía sau mà client không biết.
  4. Mọi bước phải đảo ngược được. Figma đặt "không có migration một chiều" thành yêu cầu.
  5. Đổi càng ít thứ một lúc càng tốt (Slack giữ MySQL; Figma giữ Postgres).
  6. Công cụ migrate nhanh có thể đổi luôn chiến lược (Discord: 9 ngày thì không cần cắt theo thời gian).
  7. Điều khiển tăng dần theo tải tuyệt đối (RPS), không theo % (Grab).
  8. Lên kế hoạch theo năm, không theo sprint (Netflix 7 năm, Slack 3 năm).
  9. Chuyển một phần có thể khó hơn chuyển tất cả khi phần đó dính vào trải nghiệm chung (Stack Overflow chia tier ra hai hạ tầng thì thất bại).
  10. Hai bên phải đổi trạng thái cùng lúc khi luồng ghi được chuyển: feature flag có thể cập nhật lệch giờ, nên Grab 2024 dùng mốc thời gian trong code chung (đổi lại thì rollback khó).
  11. Thuộc tính của dữ liệu quyết định chiến lược (Wix): dữ liệu có TTL thì ghi kép rồi chờ hết vòng đời; dữ liệu bất biến thì chép thoải mái; dữ liệu truy cập theo entity thì migrate tăng dần theo entity, có bảng trạng thái.
  12. Gom mọi truy cập vào một API trước khi dời dữ liệu, để API giữ request trong lúc cutover (Cloudflare 2024). Đây là cùng ý "lớp trung gian" ở quy tắc 3 nhưng ở tầng ứng dụng.
  13. Migration hàng loạt cần một "nhà máy" (migrator + hàng đợi + revert), không giao cho từng team tự làm (Monzo 2022).
  14. Có thể đổi cách tìm dữ liệu mà không dời dữ liệu (vindex lai của Etsy).
  15. Khung chung cho mọi kho dữ liệu: backfill (hoặc snapshot) + phát lại thay đổi từ đúng vị trí log + chặn ghi ngắn + kiểm + chuyển (Instacart 2020 với logical replication, Atlassian 2026 với OpenSearch). Đặt lock timeout cho DDL, vì thời gian chờ khoá cũng chặn mọi query sau (GoCardless 2020).
  16. Trạng thái gắn với nơi chạy thì không cutover bằng đổi endpoint: để cái cũ chạy hết ở chỗ cũ, định tuyến cái mới bằng quyết định tất định (băm theo ID), rollback bằng hạ tỉ lệ (Coinbase 2026 dual workers).
  17. Làm cho giai đoạn trung gian giống hệ mới (latency, auth, giới hạn) để lỗi lộ ra khi còn quay lui được; cutover chỉ bắt đầu khi đo được là sẽ xong nhanh, quá hạn thì tự lùi (WarpStream 2026).
  18. Đổi nền tảng chạy (máy ảo → Kubernetes, x86 → Arm) phải tìm các giả định ẩn ở mọi tầng: quota của cloud (Mercari 2022, giới hạn VM trên backend GCLB), công cụ build và phụ thuộc vòng (Uber 2025); artifact chạy được ở cả hai nơi (ảnh đa kiến trúc) là điều kiện để chuyển dần.
  19. Migration cả fleet hay cả lake bắt đầu bằng đo xem ai còn dùng cái cũ, rồi bật mặc định mới với danh sách ngoại lệ co dần: Slack 2023 dùng cùng một danh sách account cho module Terraform và Service Control Policy; Grab 2026 chuyển bảng theo giá trị và chi phí, không đổi hết. Slack 2023 Grab 2026
  20. Khi hai định dạng phải sống chung lâu, đặt lớp chuyển hướng để người dùng không cần biết bảng đang ở định dạng nào, và tính chi phí một lần của chính migration vào kế hoạch (Grab 2026 UnifiedSparkCatalog). Grab 2026
  21. Migrate từng phần mà để lại DB chung và ánh xạ ID ở môi trường cũ thì mỗi đợt lại thêm một lớp đồng bộ; khi đã qua nhiều đợt, cân nhắc chuyển phần lõi trước hoặc thiết kế lại. trivago 2024
  22. Đổi định dạng lưu trữ có pha hai hay bị quên: ghi lại toàn bộ dữ liệu cũ; chỉ gỡ đường đọc dạng cũ khi có tín hiệu "đã xong" đáng tin (Kubernetes 2026 storedVersions). Viết lại công cụ quan trọng thì giữ nguyên giao diện, bật mặc định ở một release và xoá đường cũ ở release sau (Kubernetes 2026 kpromo). Kubernetes 2026 Kubernetes 2026
  23. Hai kho cùng tồn tại thì kho phụ có thể sai âm thầm nhiều năm: đối chiếu dữ liệu hai bên trên cụm thật trước khi đổi nguồn sự thật, và làm sạch cả trạng thái đã ghi (etcd 2025). Muốn đổi nghĩa giá trị đã lưu, thêm trường mới + diễn giải lúc đọc thay vì viết lại tại chỗ (Slack 2026). etcd (CNCF) 2025 Slack 2026
  24. Một điểm mà mọi client đi qua (gateway, service bootstrap) là đòn bẩy migration: đổi backend hoặc chia traffic dần mà client không phải phát hành lại (LinkedIn 2025, Postman 2019). ClickHouse 2026 Postman 2020
  25. Nâng thứ dùng chung lên bản tương thích ngược trước, rồi chạy hai thế hệ song song với cờ định tuyến theo từng job: Slack 2024 nâng Hive Metastore để cụm Spark 2 và Spark 3 cùng đọc, chuyển job bằng một cờ boolean, so khớp chính xác dữ liệu quan trọng thay vì lấy mẫu. Slack 2024
  26. Đổi nền tảng chạy (VM → Kubernetes) phải test ở tải đỉnh trước khi chuyển: giới hạn mặc định của nền tảng mới (cổng NAT, DNS, vCPU hyper-thread) không lộ ra ở tải thấp và ứng dụng không hề đổi. ASOS 2021 ASOS 2021
  27. Cầu nối chạy được hai chiều cho phép đổi cả lá lẫn khung mà không có cutover; "xong" là lúc giàn giáo cũ hết việc. Doximity 2026

Câu hỏi mở

  • Ghi kép (Discord, Slack, Shopify 2025, Wix, Quora) hay replication/CDC + cutover (GitHub, Figma, Cloudflare)? Figma tránh ghi kép vì nhất quán; Cloudflare tự viết CDC bằng trigger thay vì pgLogical vì cần chuyển được hai chiều và audit được. Các nguồn không so sánh trực tiếp. Tạm hiểu: ghi kép hợp khi đổi loại kho dữ liệu (không replicate được với nhau, như Cassandra → DynamoDB, HBase → MyRocks); replication/CDC hợp khi cùng engine.
  • Liên hệ: Hạ tầng tìm kiếm (đổi hình index tìm kiếm online, re-index), Pipeline dữ liệu và analytics (shadow/reverse shadow cho pipeline dữ liệu, đổi định dạng data lake).
  • Liên hệ: Quản lý fleet và migrate code hàng loạt (thay đổi code và cấu hình trên hàng nghìn repo: BOM, Fleetshift, automerge, recipe OpenRewrite).