Tìm kiếm
31 kết quả cho “shard theo domain”. Tìm không phân biệt dấu.
- 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.
- How we modified our infrastructure to deploy an EU data center Bài tóm tắt · Asana · 2020
…liệu; Asana mở hạ tầng ở châu Âu (12/2019). - Từ 2015 Asana shard theo domain (mỗi domain nằm trọn trong một database, mỗi DB chứa nhiều domain), cộng một master shard lưu user và…
- Building a fault-tolerant metrics storage system at Airbnb Bài tóm tắt · Airbnb · 2026
…ượng và tốc độ series, số rule, chu kỳ đánh giá). - Shuffle sharding: mỗi tenant chỉ ghi vào một tập con node storage và query chỉ dùng một tập con query worker; một tenant bị tấn…
- 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.
- 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:
- Độ 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.
- 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ả…
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- 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…
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- 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:
- 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.
- 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…
- 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…
- Zillow Công ty Thành viên
Zillow cho thấy một công ty dữ liệu đi từ ứng dụng web có cache tự làm sang nền tảng dữ liệu, ML và thí nghiệm dùng chung. Năm 2012 các sản phẩm mới đã chạy trên AWS: nền tảng website cho môi giới trên WordPress dùng…
- Netflix Công ty Thành viên
Sự cố hỏng DB năm 2008 dẫn tới 7 năm lên AWS theo hướng cloud-native . Bài kiểm tra lớn đầu tiên là sự cố AWS US-East năm 2011: kiến trúc stateless, nhiều zone, fallback chịu được, nhưng rút khỏi zone phải làm tay. Từ…
- 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…
- 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ẻ…
- On WordPress Scaling and Performance, The Zillow Way Bài tóm tắt · Zillow · 2012
…ản mà vẫn đúng (). - Chia khách theo hash nhất quán là cách sharding rẻ nhất khi đơn vị là tenant độc lập (, ). Bài học cho SWE - Invalidation thô (xoá cả domain) chấp nhận được kh…
- Shopify Công ty Thành viên
Năm 2015 không còn mua được DB to hơn nên Shopify shard, rồi phát hiện thao tác lặp mọi shard làm mất cô lập lỗi. Kiến trúc pod (mỗi request chỉ chạm một tập datastore cô lập, Pod Mover dời pod sang DR) ra đời .…
- Asana Công ty Thành viên
Phần mềm quản lý công việc; hai nguồn trong wiki đều về lớp dữ liệu. Asana shard theo domain (tenant) từ 2015, nhưng một phần dữ liệu dùng chung cho mọi workspace vẫn nằm trong một MySQL trên RDS. Mùa hè 2019, ba lần…
- Partitioning GitHub's relational databases to handle scale Bài tóm tắt · GitHub · 2021
…ime, hai công cụ độc lập để giảm rủi ro: - Vitess (vertical sharding qua VTGate/VTTablet/VReplication). - Quy trình write-cutover tự viết: cluster mới replicate từ cluster cũ; Prox…
- Square Công ty Thành viên
Công ty thanh toán; nguồn duy nhất trong wiki là bài 11/2018 về Cash App. Cash App bắt đầu từ một thử nghiệm Hack Week trên một MySQL; cuối 2016 đã dùng hết cache, chuyển dữ liệu cũ, replica đọc và phần cứng đắt, nên…
- Migrating billions of records: moving our active DNS database while it's in use Bài tóm tắt · Cloudflare · 2024
Theo W3Techs (10/2024), Cloudflare là authoritative DNS của 14,5% website. Zone lớn nhất có ~4 triệu record, phần lớn zone dưới 100.
- Ele.me Công ty Thành viên
Nền tảng giao đồ ăn (sau thuộc Alibaba). Năm 2012 mọi module lõi nằm trong một ứng dụng Python tên Zeus. Năm 2015 team đơn hàng 4 người tách Zeus thành các service qua sáu bước, từ module trong repo chung tới deploy vật…
- Database-per-User Architecture With Isolated Application Environments Bài tóm tắt · Neon · 2024
Bài trước trong loạt: database-per-user với môi trường ứng dụng dùng chung (một bản ứng dụng nói chuyện với DB riêng của từng khách). Bài này: môi trường ứng dụng cô lập, mỗi khách một bản sao toàn bộ hệ thống.
- Incident Report: March 30th, 2026 — Authenticated user data cached Bài tóm tắt · Railway · 2026
…ớc khi thay đổi lên production. - Rollout CDN chia nhỏ theo shard trong nhiều giờ thay vì vài phút. - Ưu tiên an toàn và bảo mật hơn tính năng mới trong giai đoạn tăng trưởng nóng.…
- GitHub Công ty Thành viên
Rails + một MySQL; sau đó tách vài tính năng, thêm replica, ProxySQL; nhưng lõi vẫn là cluster mysql1 được scale dọc liên tục. Từ 2019 họ tách ảo bằng schema domain + linter rồi dời vật lý bằng Vitess hoặc write-cutover…
- Report on our investigation of the 2025-10-20 incident in AWS us-east-1 Bài tóm tắt · PlanetScale · 2025
20/10/2025, AWS us-east-1 gặp sự cố lớn bắt đầu từ cấu hình DNS sai ở một nhà cung cấp. Sau đó là nhiều giờ thiếu năng lực và mạng chập chờn.
- Railway Công ty Thành viên
Nền tảng PaaS tự vận hành datacenter, mỗi site nối ít nhất ba nhà mạng Tier 1. Sự cố 2/7/2026: ngắt một nhà mạng hỏng làm một site thế hệ đầu (nhận default route từ nhà mạng) mất internet 20 phút; sau đó kết nối storage…
- 5-year Evolution of Ele.me's Transaction System - Part 1 Bài tóm tắt · Ele.me · 2020
…là nền tảng giao đồ ăn, sau thuộc Alibaba). Các phần sau: (shard, message broadcast), (test, diễn tập lỗi), (Redis, polling), (sự cố RabbitMQ), (tách domain). Bối cảnh - 2012: Zeu…