Tìm kiếm
40 kết quả cho “cache hit rate”. Tìm không phân biệt dấu.
- 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:
- Slack's Incident on 2-22-22 Bài tóm tắt · Slack · 2022
…là trang lỗi. - Dữ liệu trên Vitess chia nhiều keyspace (). Cache là Memcached, Mcrouter định tuyến bằng consistent hashing. Mcrib là control plane mới của cache: theo dõi Consul,…
- Scaling Cache Infrastructure at Pinterest Bài tóm tắt · Pinterest · 2020
…[bài gốc](https://medium.com/pinterest-engineering/scaling-cache-infrastructure-at-pinterest-422d6d294ece) Bối cảnh - Tầng cache phân tán nằm gần đáy stack, đứng trước nhiều servi…
- 25% or 6 to 4: The 11/6/23 Authentication Outage Bài tóm tắt · Discord · 2023
…hau: cụm thiếu capacity ; một NVMe ở node b-2 suy giảm; row cache của các node b vừa restart còn trống (với vài cụm, tỉ lệ cache hit phải đạt ngưỡng mới restart an toàn, mà quy trì…
- How Etsy caches: hashing, Ketama, and cache smearing Bài tóm tắt · Etsy · 2017
…bình — [bài gốc](https://www.etsy.com/codeascraft/how-etsy-caches) Bối cảnh - Etsy dùng memcached làm look-aside cache (kết quả query DB, search, tính toán đắt) cho PHP và Java, v…
- Inside Stream's Real-Time Architecture for Trading & Investing Apps Bài tóm tắt · Stream (GetStream) · 2026
…mở app cùng lúc. Thay đổi chính - Feed: fan-out on read có cache ("materialized feed"). Mỗi activity lưu một lần (không chép theo follower như push). Khi đọc, chỉ lấy phần mới kể…
- A Lightweight Distributed Architecture to Handle Thousands of Library Releases at eBay Bài tóm tắt · eBay · 2022
…pendency) có thể lớn hơn chính việc; worker sống lâu và giữ cache cục bộ thắng worker dùng một lần. - Theo eBay, mẫu "service trung tâm giữ hàng đợi + worker kéo việc" dùng lại đượ…
- The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds Bài tóm tắt · Twitter · 2013
…ID thành nội dung bằng multiget song song từ các service có cache riêng (cache user chứa toàn bộ user base, cache tweet giữ khoảng 1,5 tháng gần nhất). Khoảng 400 ms qua API. - Sea…
- 6 Event-Driven Architecture Patterns — Part 1 Bài tóm tắt · Wix · 2020
Team data-streams của Wix lo hạ tầng event-driven trên Kafka cho hơn 1.400 microservice (2020). Bài là ba mẫu dùng thực tế ở Wix, mỗi mẫu một use case.
- Scaling and benchmarking a critical message bus using a new indexing strategy Bài tóm tắt · Jane Street · 2026
…tính qua toàn bộ luồng: kém về thuật toán nhưng thân thiện cache CPU nên từng đủ nhanh. Khi số client recovery tăng, có server lên 100% CPU, client "rơi khỏi tip" không đuổi kịp;…
- Service Architecture at SoundCloud — Part 1: Backends for Frontends Bài tóm tắt · SoundCloud · 2021
…giờ ; - BFF đảm nhận rate limit, xác thực, làm sạch header, cache control nhờ một thư viện edge dùng chung ; bản mới của thư viện được rollout bán tự động tới mọi BFF trong vài giờ…
- Splitting a Monitoring Monolith into Separate Components Bài tóm tắt · trivago · 2018
…ối (Symfony, Orchestra) kéo metric từ API của các CDN (ChinaCache, Edgecast…) và vài dịch vụ khác, đẩy vào InfluxDB qua Graphite. Code nhiều phụ thuộc chéo giữa các module. Thay đổ…
- Rearchitecting the Workflows control plane for the agentic era Bài tóm tắt · Cloudflare · 2026
…e: kiểm phiên bản control plane, dùng thông tin workflow đã cache ở location đó (thiếu mới hỏi Account), chỉ ghi metadata cần thiết vào chính Engine; việc báo cho control plane chạ…
- Upscaling LinkedIn's Profile Datastore While Reducing Costs Bài tóm tắt · LinkedIn · 2023
…p đôi mỗi năm (2023). Profile hơn 99% là đọc. - Lịch sử: memcached làm cache đọc trước DB, khó vận hành (suy giảm khi mở rộng, thay node, cache lạnh). Chuyển từ Oracle sang Espress…
- Code caching for JavaScript developers Bài tóm tắt · V8 (Google) · 2019
…lời khuyên cho người viết website, nhưng mô tả rõ thiết kế cache hai tầng của Chrome/V8. Wiki giữ phần thiết kế và các cách cache bị vô hiệu. Bối cảnh - Parse + compile JavaScript…
- 5-year Evolution of Ele.me's Transaction System - Part 4 Bài tóm tắt · Ele.me · 2020
…ớ, kết nối, hit rate, số key). Code dùng Redis cho ba việc: cache (bảng, API), distributed lock, sinh số thứ tự cho merchant. Thay đổi chính - Chuyển cụm cache thì "sốc": cụm cũ 55…
- The Events Rail: Inside Atlassian's Webhook Delivery Platform Bài tóm tắt · Atlassian · 2026
…eue. Một pod matching đánh giá hàng chục nghìn lần/giây khi cache ấm. - Event Delivery (network-bound): giữ hàng trăm HTTP exchange đồng thời mỗi pod; recipient phản hồi từ vài chụ…
- Optimizing Elasticsearch for Low Latency, Real-Time Recommendations Bài tóm tắt · Zillow · 2022
…hất. Thay đổi chính - Service rt-recs (Java + Python): kiểm cache Redis → lấy hồ sơ người dùng (cập nhật gần realtime) → Elasticsearch sinh tối đa 100 ứng viên từ khoảng 1,3 triệu…
- Himeji: A Scalable Centralized System for Authorization at Airbnb Bài tóm tắt · Airbnb · 2021
…ng: orchestration (đọc cấu hình, phát lệnh fetch, route tới cache bằng consistent hashing), cache (shard + replica, mỗi shard một instance trên mỗi AZ, nhắm hit rate khoảng 98%), d…
- Scaling Time Series Data Storage — Part II Bài tóm tắt · Netflix · 2018
…ông chứa vài năm gần đây nên phải bổ sung từ Recent/Past. - Cache EVCache dựng giống kiến trúc lưu trữ, hit rate gần 99%; cache "Summary" giữ tóm tắt nén của toàn bộ lịch sử. - Kết…
- How we built Claude Code auto mode: a safer way to skip permissions Bài tóm tắt · Anthropic · 2026
…đoạn 2 suy luận đầy đủ với cùng prompt (gần như toàn bộ là cache hit). Prompt là template cố định với ba chỗ tuỳ biến: môi trường tin cậy (mặc định chỉ tin repo git hiện tại), luậ…
- 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:
- 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…
- 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:
- 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…
- Độ 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.
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấ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…
- 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,…
- 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.
- 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…
- 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ỡ:
- 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.
- 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…
- 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".
- 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ả…
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- 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:
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.