Tìm kiếm
40 kết quả cho “failover capacity”. Tìm không phân biệt dấu.
- The process: Implementing Yelp's failover strategy Bài tóm tắt · Yelp · 2021
…— [bài gốc](https://increment.com/reliability/yelp-traffic-failover-strategy/) Bối cảnh - Yelp phục vụ từ hai region AWS ở hai bờ nước Mỹ. Request chỉ đọc (phần lớn traffic) đi tớ…
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Using the Gini Coefficient to Plan Edge Capacity Bài tóm tắt · Fastly · 2026
…ước, khi khách chuyển traffic từ nhà cung cấp khác sang lúc failover thì sao. - Thử AutoML, neural net, mô hình cây, ensemble, mô hình time-series, cả LLM: tốt cho ngày bình thường…
- The Great Re-shard: adding Postgres capacity (again) with zero downtime Bài tóm tắt · Notion · 2023
…do query không tất định như LIMIT hoặc trễ replication). - Failover từng DB bằng script: tạm dừng traffic ở PgBouncer và để query đang chạy xong → kiểm tra replication đã đuổi kịp…
- From One Horizontal Scaling Controller to Many: Evolving Uber's Compute Platform Bài tóm tắt · Uber · 2026
…uyết số replica (Up) và một bên áp và báo (UDC). - Từ 2023, failover đổi cách: Uber chạy active-active giữa các region; khi failover, region còn lại phải có đủ compute rảnh. Cách c…
- Moving to DynamoDB to Increase Application Resiliency Bài tóm tắt · CapitalOne · 2021
…ck active-active ở hai region AWS (East, West) , service tự failover gần như tức thì, trừ PostgreSQL : primary ở một region, read replica ở region kia, promote mất 10–15 phút . - R…
- AWS Lessons Learned for Data Processing Pipelines Bài tóm tắt · Expedia · 2016
…- Đọc giới hạn của tính năng replication trước khi thiết kế failover dựa trên nó. Liên quan - Cùng công ty: · - ·…
- Shadow Engine Recovery in NVIDIA Dynamo Bài tóm tắt · NVIDIA · 2026
…file lock) để bầu active: không cần heartbeat hay lease cho failover trong cùng máy. - Phân loại lỗi theo phạm vi (process, node, phần cứng) rồi chọn cơ chế phục hồi cho từng loại;…
- Deployment of etcd on AWS EC2 Bài tóm tắt · etcd · 2017
etcd là kho key-value nhất quán mạnh, replicate đồng bộ bằng Raft; là nền cho control plane Kubernetes, lock phân tán, config, secret.
- Độ tin cậy và multi-region Chủ đề Thành viê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.
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- 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…
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏ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".
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- Migration không downtime Chủ đề Thành viê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.
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- 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…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- Meta Công ty Thành viên
Facebook khởi đầu trên LAMP với mỗi trường đại học một DB; mở rộng bằng Memcache, rồi TAO, rồi data center riêng, edge cạnh ISP và region nhiều toà nhà. Giai đoạn 2010–2020 là các ca góc của hệ phân tán: bất nhất cache…
- Active-Active for Multi-Regional Resiliency Bài tóm tắt · Netflix · 2013
…m region (giữ một phiên thiết bị trong một region), chế độ "failover" cho một region, và trần traffic tối đa : vượt trần thì trả lỗi ngay, để bảo vệ tầng dưới khi service đang scal…
- Achievers Công ty Thành viên
Để mở rộng sang nhiều region với data residency và có failover giữa các cụm GKE, Achievers chuyển từ Kong sang Istio làm cả gateway lẫn service mesh (migration xong cuối 2020) và gặp một loạt vấn đề do sidecar . Phần 2…
- Eliminating toil with fully automated load testing Bài tóm tắt · LinkedIn · 2019
…công và dễ sai trên traffic thật. Bài học cho SWE - Cơ chế failover giữa DC cũng là công cụ load test: dồn traffic thật vào một DC để đo trần. - Tự động hoá việc điều khiển theo m…
- Stack Overflow Công ty Thành viên
Phản ví dụ nên đọc sớm cho niềm tin "lớn thì phải scale out". Năm 2009, với 16 triệu page view mỗi tháng, Stack Overflow chạy hai web server và một SQL Server, chạm giới hạn thì nâng RAM; theo Jeff Atwood, phần cứng rẻ…
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…
- Building Git infrastructure for agent-scale development Bài tóm tắt · GitHub · 2026
Tải tăng vọt vì agent (theo GitHub): tổng sự kiện Git từ 218,2 tỉ lên 473,3 tỉ mỗi tháng (9/2025 → 8/2026); push tăng 4,9 lần trong một năm (0,69 → 3,35 tỉ/tháng); 7,38 tỉ commit trong tháng 9/2026, gấp hơn năm lần năm…
- Scaling Slack's Job Queue Bài tóm tắt · Slack · 2017
…ưu tiên Kafkagate cùng AZ (giảm latency và phí giữa AZ, vẫn failover được). - JQRelay (Go, không trạng thái): mỗi topic một relay nhờ khoá Consul; chỉ tiến offset Kafka khi đã ghi…
- Load Testing Kubernetes: Resolving bottlenecks and improving performance (Part 2) Bài tóm tắt · Achievers · 2023
…ỗi/latency; throughput gấp 4, đủ để một region gánh traffic failover khi region kia sự cố (theo Achievers, 2023). Bài học cho SWE - Load test lộ ra nút thắt ở những lớp không ai ng…
- Airbnb Công ty Thành viên
Airbnb chuyển từ một ứng dụng Rails khổng lồ sang SOA, và lộ ra chi phí test: deep integration test cho mọi service không scale, nên họ chuyển sang tháp test + CD có canary analysis . Năm 2025 với ba trụ sản phẩm, data…
- When The Cloud Gets Dark — How Amazon's Outage Affected Airbnb Bài tóm tắt · Airbnb · 2011
Toàn bộ hạ tầng Airbnb năm 2011 trên AWS. Sự cố us-east tháng 4/2011: mạng ở hai AZ mất kết nối, EBS tự re-mirror nhưng không đủ capacity dự phòng, volume EBS treo hoặc I/O cực chậm.
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- How we optimized Magic Pocket for cold storage Bài tóm tắt · Dropbox · 2019
…ng cũng là đường dự phòng thì không có bất ngờ capacity khi failover. Liên quan - · - Các mốc khác của Magic Pocket: · ·…
- Chaos Testing an Application on AWS Bài tóm tắt · Goldman Sachs · 2022
…Ba nhóm lỗi theo bán kính ảnh hưởng: hạ tầng (tắt ECS task, failover hoặc tắt cụm DB, tới mất AZ/region); mạng (phá kết nối VPC endpoint tới dependency); hình dạng traffic bằng k6…
- Improving Resiliency and Stability of a Large-scale Monolithic API Service Bài tóm tắt · LinkedIn · 2017
…g kế thừa config chung; - ước lượng cỡ cụm = QPS tối đa khi failover colo × 1,2 / QPS tối đa mỗi host. Thực tế sai từ 30–300%, nên phải đo lại; - chuyển traffic nội bộ (Rest.li D2)…