Tìm kiếm
20 kết quả cho “Zero downtime”. Tìm không phân biệt dấu.
- The Great Re-shard: adding Postgres capacity (again) with zero downtime Bài tóm tắt · Notion · 2023
Cụm "space shards" lưu toàn bộ nội dung workspace (block, comment, collection), chia theo workspace ID: 32 DB Postgres, mỗi DB chứa 15 logical schema; mỗi workspace nằm trọn trên một shard. Giữa web server và DB là…
- Zero-downtime Postgres migrations - the hard parts Bài tóm tắt · GoCardless · 2015
…Độ khó: Trung bình — [bài gốc](https://gocardless.com/blog/zero-downtime-postgres-migrations-the-hard-parts/) Bối cảnh - GoCardless là công ty thanh toán: API ngừng nhận request t…
- How We Replaced Our Data Pipeline With Zero Downtime Bài tóm tắt · Twilio · 2014
…gineering/2014/06/26/how-we-replaced-our-data-pipeline-with-zero-downtime) Bối cảnh - Mỗi cuộc gọi hay tin nhắn đi qua các trạng thái in-flight (đổ chuông, đang gọi, xếp hàng), rồi…
- This Rocket Ain't Stopping - Achieving Zero Downtime for Rails to Golang API Migration Bài tóm tắt · Grab · 2016
…Độ khó: Trung bình — [bài gốc](https://engineering.grab.com/zero-downtime-migration) Bối cảnh - Grab đang chuyển từ Rails + NodeJS sang kiến trúc service toàn Go . Một phần mục tiê…
- Wix Inbox Journey: 3 Approaches for Zero Downtime Database Migration Bài tóm tắt · Wix · 2021
…www.wix.engineering/post/wix-inbox-journey-3-approaches-for-zero-downtime-database-migration) Bối cảnh - Wix có hơn 200 triệu user ở 190 nước. Ứng dụng chat của Wix Inbox (trong bộ…
- How Stripe's document databases supported 99.999% uptime with zero-downtime data migrations Bài tóm tắt · Stripe · 2024
…how-stripes-document-databases-supported-99.999-uptime-with-zero-downtime-data-migrations) Bối cảnh - Stripe chọn MongoDB từ 2011 (Atlas chưa có) và xây DocDB , DB-as-a-service nội…
- Zero Ops Schema Migration: WarpStream Schema Linking Bài tóm tắt · WarpStream · 2025
…khó: Trung bình — [bài gốc](https://www.warpstream.com/blog/zero-ops-schema-migration-warpstream-schema-linking) Bài ra mắt tính năng của nhà cung cấp; mọi nhận định là theo WarpSt…
- How we seamlessly migrated high volume real-time streaming traffic with zero data loss and duplication Bài tóm tắt · Grab · 2024
Grab tách phần đọc và phần ghi của một backend service thành hai service riêng để scale độc lập.
- Database Federation: Decentralized and ACL-Compliant Hive Databases Bài tóm tắt · Uber · 2026
Một data warehouse của mảng Delivery có hơn 16.000 dataset Hive, 10 PB của nhiều domain nằm trong một database Hive do một team trung tâm sở hữu. Từng giúp onboard và tìm dữ liệu dễ, nhưng khi lớn thì thành gánh nặng:
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Query planner và hiệu năng truy vấn Chủ đề Thành viên
Database quan hệ không chạy SQL theo đúng cách nó được viết. Query planner chọn một plan (dùng index nào, join kiểu gì: nested loop, merge, hash; dừng sớm khi có LIMIT hay không) dựa trên thống kê về dữ liệu: số dòng,…
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Scaling Prometheus to billions of samples a second Bài tóm tắt · Hudson River Trading · 2021
HRT dùng Prometheus làm thành phần chính để giám sát hạ tầng toàn cầu, cả metric host lẫn metric service, cho môi trường giao dịch live và cụm nghiên cứu. Một instance scale lên rất xa nhưng vẫn có trần phần cứng.
- WhatsApp Công ty Thành viên
WhatsApp là ca hiếm: blog kỹ thuật gần như chỉ kể hai giai đoạn, và hai giai đoạn ấy giải hai bài khác hẳn nhau. Giai đoạn Erlang (2011–2014) là câu chuyện tối ưu một hệ nhỏ người: năm 2012, một server FreeBSD + Erlang…