Tìm kiếm
40 kết quả cho “edge cache”. Tìm không phân biệt dấu.
- Flannel: An Application-Level Edge Cache to Make Slack Scale Bài tóm tắt · Slack · 2017
…gốc](https://slack.engineering/flannel-an-application-level-edge-cache-to-make-slack-scale/) Bối cảnh - Slack thiết kế cho team vài trăm người: khi khởi động, client gọi rtm.start…
- 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:
- Using the Gini Coefficient to Plan Edge Capacity Bài tóm tắt · Fastly · 2026
…ốc](https://www.fastly.com/blog/using-gini-coefficient-plan-edge-capacity) Bài của nhà cung cấp, kể bởi người xây mô hình; số liệu sai số do Fastly tự đo, ghi "theo Fastly". Bối cả…
- Incident Report: March 30th, 2026 — Authenticated user data cached Bài tóm tắt · Railway · 2026
…ache-Control: private/no-store . - Thay đổi cấu hình ở tầng edge có bán kính ảnh hưởng toàn cầu, nên cần rollout từ từ như code (). - 32 phút từ deploy tới phát hiện: chưa có tín h…
- Inside Stream's Real-Time Architecture for Trading & Investing Apps Bài tóm tắt · Stream (GetStream) · 2026
…nối với server không trước khi push. - Chat: client nối vào edge gần nhất (handshake, xác thực, rate limit tại edge), edge → origin qua kết nối mở sẵn; SDK giữ trạng thái cục bộ để…
- How we built custom emoji Bài tóm tắt · Notion · 2025
…ào: cân nhắc tải hết lúc khởi động app hay tải động qua một edge cache. Chọn tải hết lúc khởi động (sau các request quan trọng) vì nhanh làm và picker mở tức thì; dựng edge cache n…
- Diving into Uber's cutting-edge data infrastructure Bài tóm tắt · Onehouse · 2024
…gốc](https://www.onehouse.ai/blog/diving-into-ubers-cutting-edge-data-infrastructure) Nguồn thứ cấp: Onehouse (công ty do người tạo ra Hudi ở Uber lập) tóm tắt talk của Girish Bali…
- Moving Railway's Frontend Off Next.js Bài tóm tắt · Railway · 2026
…scord. - Từ bỏ: tối ưu ảnh dựng sẵn (thay bằng tối ưu ảnh ở edge của Fastly), vài thư viện hệ sinh thái (tự viết thay), độ trưởng thành. - Fastly phục vụ phần lớn traffic từ edge;…
- Prefetch Caching of Items at eBay Bài tóm tắt · eBay · 2020
…phần trên màn hình cải thiện 10%. Hướng tiếp: đưa cache ra edge, và cache không theo user. Vì sao - Thời gian user đọc trang tìm kiếm là cửa sổ rảnh để làm trước việc của trang ti…
- Active-Active for Multi-Regional Resiliency Bài tóm tắt · Netflix · 2013
…n theo latency vì traffic sẽ dịch chuyển khó đoán. - Zuul ở edge: phát hiện request đi nhầm region (giữ một phiên thiết bị trong một region), chế độ "failover" cho một region, và t…
- Meta's Infrastructure Evolution and the Advent of AI Bài tóm tắt · Meta · 2025
…y. - Nhiều DC kéo theo hai bài toán: - đưa user tới DC: xây edge , đặt máy cạnh từng ISP, peering; đến nay có hàng trăm POP; - nhân bản toàn bộ stack ở mỗi DC để trải nghiệm như nh…
- Cross Shard Transactions at 10 Million Requests Per Second Bài tóm tắt · Dropbox · 2018
…-transactions-at-10-million-requests-per-second) Bối cảnh - Edgestore là lớp trừu tượng trên hàng nghìn node MySQL, giữ hàng petabyte metadata, hơn 10 triệu request/giây. Developer…
- FollowFeed: LinkedIn's Feed Made Faster and Smarter Bài tóm tắt · LinkedIn · 2016
…on. - Scatter-gather chịu tail latency của node chậm nhất: hedged request và giảm tải ở client là phần của thiết kế, không phải tối ưu sau. Liên quan - - (hai năm sau, chính cơ chế…
- LIquid: The soul of a new graph database, Part 2 Bài tóm tắt · LinkedIn · 2020
…an hằng. - Ngôn ngữ là Datalog , chỉ cho khẳng định quan hệ Edge, mọi rule quy về Edge; ghép được (composable). Kết quả là bảng như SQL hoặc subgraph. - Schema tự mô tả trong đồ th…
- Protecting our platform from spikes in usage by reducing load from the Monzo app Bài tóm tắt · Monzo · 2023
…thẻ . Thay đổi chính - Đo lãng phí trước: log 1/1000 user ở edge proxy, ghi URL kèm hash của response (không log dữ liệu nhạy cảm). Kết quả: khoảng 70% GET có một request giống hệt…
- The feedback loops behind Kubernetes Bài tóm tắt · PlanetScale · 2026
…r election: tức là dựng lại Kubernetes. Cơ chế (theo bài) - Edge-triggered notification, level-triggered logic. Hành động theo sự kiện ("replica tăng 2") là mong manh: controller t…
- How we migrated Dropbox from Nginx to Envoy Bài tóm tắt · Dropbox · 2020
…L; goroutine mỗi request tốn bộ nhớ khi kết nối nhiều) mà ở edge thì không autoscale dễ; TLS của Go không có FIPS; không có cộng đồng ngoài Dropbox. Thay đổi chính - Hiệu năng: đo…
- A look inside our sixth generation of server hardware Bài tóm tắt · Dropbox · 2022
…B mỗi rack (8 chassis), NIC 100 Gb. - Database (Diego): cho Edgestore, File Journal, metadata của Magic Pocket: mật độ rack gấp đôi, CPU nhiều hơn 60%, SSD NVMe 16 TB (gấp đôi flas…
- Journey to the cloud part II: Migrating Stack Overflow for Teams to Azure Bài tóm tắt · Stack Overflow · 2023
…ách này phức tạp và dễ hỏng, "đủ tốt cho lift-and-shift". - Edge: giữ Fastly, thêm hai Azure Application Gateway (trong và ngoài, hai subnet). mTLS giữa Fastly và Gateway để chỉ Fa…
- How we optimized Magic Pocket for cold storage Bài tóm tắt · Dropbox · 2019
…ứ hai nếu request đầu chưa về sau một ngân sách thời gian (hedged request theo Jeff Dean). - Luôn chạy kịch bản xấu nhất: đọc cold lúc nào cũng phải ghép fragment từ nhiều region,…
- Concourse: Generating Personalized Content Notifications in Near-Real-Time Bài tóm tắt · LinkedIn · 2018
…nội dung) để cache feature của actor tại chỗ. - Fanout gọi Edges API lấy kết nối và follower, sinh một payload cho mỗi người nhận, gộp nếu một người nối qua nhiều cạnh. - Feature…
- 500 Tbps of capacity: 16 years of scaling our global network Bài tóm tắt · Cloudflare · 2026
2010: khởi đầu từ một văn phòng ở Palo Alto, một nhà cung cấp transit (nLayer, nay là GTT), một reverse proxy cài bằng cách đổi hai nameserver.
- Độ 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.
- 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…
- 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,…
- 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ỡ:
- 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.
- 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.
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- 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".
- 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.
- 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.
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Giao dịch phân tán và nhất quán xuyên service Chủ đề Thành viên
Với một DB quan hệ, BEGIN … COMMIT lo hết. Khi dữ liệu bị chia (shard, tách service, thêm Redis bên cạnh Postgres), một thao tác nghiệp vụ chạm nhiều nơi, và câu hỏi khó nhất trở thành "timeout rồi, việc đó đã xảy ra…
- 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.