Tìm kiếm
34 kết quả cho “hot feed cache”. 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:
- 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:
- Inside Stream's Real-Time Architecture for Trading & Investing Apps Bài tóm tắt · Stream (GetStream) · 2026
…oá nóng hết hạn thì một request dựng lại, số còn lại chờ); "hot feed cache" tuỳ chọn phục vụ một thứ tự chung cho mọi người đọc feed chung (kiểu "mã được bàn nhiều nhất hôm nay");…
- The feedback loops behind Kubernetes Bài tóm tắt · PlanetScale · 2026
…lượng đĩa, thao tác volume đang chờ cooldown). Gom một snapshot ở đầu vòng , mọi quyết định đọc từ đó, không hỏi lại giữa chừng (nếu không, đầu vòng thấy leader, giữa vòng thấy rep…
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…ỏ Cassandra, Mongo, Membase. - Redis cho home feed chỉ snapshot mỗi 3 giờ, không replication: mất máy thì mất vài giờ dữ liệu, chấp nhận để đơn giản (bình luận dưới bài phản bác rằ…
- Building a dynamic and responsive Pinterest Bài tóm tắt · Pinterest · 2018
2015: phần lớn nội dung được sinh sẵn cho user trước khi họ đăng nhập, lưu tĩnh trong HBase. Kiến trúc này đưa Pinterest tới 100 triệu MAU.
- Building Pubsub for 50M concurrent socket connections Bài tóm tắt · Disney Hotstar · 2019
…2019 · 3. Quy mô lớn · Độ khó: Khó — [bài gốc](https://blog.hotstar.com/building-pubsub-for-50m-concurrent-socket-connections-5506e3c3dabf) Đọc toàn văn qua trình duyệt (blog.hotst…
- Analysis of recent downtime & what we're doing to prevent future incidents Bài tóm tắt · Asana · 2019
…(13/8). Kỳ vọng thường lệ: phần cứng hỏng thì failover sang hot spare mất vài phút, ứng dụng retry. - Có cơ chế chống phản hồi dương/sụp dây chuyền do quá tải ở nơi khác, nhưng khô…
- 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.
- 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…
- 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.
- 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,…
- 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…
- 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.
- 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".
- 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…
- 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.
- 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:
- 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…
- 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…
- 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ì…
- 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ả…
- 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…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- Thử nghiệm A/B và nền tảng experimentation Chủ đề Thành viên
Khi nhiều team cùng thay đổi một sản phẩm, "ship rồi xem metric" không còn trả lời được thay đổi nào gây ra gì. Thí nghiệm có đối chứng trả lời được, nhưng ở quy mô lớn nó thành một hệ thống: gán người dùng vào biến thể…
- Tracing phân tán và log theo request Chủ đề
Khi một request đi qua hàng chục service, metric của từng service cho biết có chậm, log của từng service cho biết từng mảnh; không cái nào trả lời "request này chậm vì đâu" hay "trang này tốn bao nhiêu". Tracing phân…
- Pinterest Công ty Thành viên
Năm 2015 Pinterest sinh sẵn nội dung cho mọi user và lưu trong HBase, cách đã đưa họ tới 100 triệu MAU nhưng tốn lưu trữ và khó thử nghiệm. Họ xây 9 hệ thống C++/RocksDB để sinh feed lúc đọc . Phía dưới là tầng cache…
- 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…
- What Powers Instagram: Hundreds of Instances, Dozens of Technologies Bài tóm tắt · Instagram · 2011
…RAM ; EBS ghép software RAID. - Streaming replication, snapshot EBS (đóng băng XFS để snapshot nhất quán). - PgBouncer pool kết nối, được nhắc là thay đổi có tác động lớn tới hiệu…
- Stream (GetStream) Công ty Thành viên
Stream là nhà cung cấp API feed, chat và video; nguồn duy nhất trong wiki (9/2026) là bài tiếp thị cho app giao dịch nhưng có mô tả kiến trúc: feed fan-out on read có cache kết quả trong TiKV với cursor theo từng nguồn,…
- Active-Active Shared-Nothing Database Architecture Bài tóm tắt · CapitalOne · 2020
…ung chính - AASN khác high availability: HA có thể đạt bằng hot standby ở vùng khác (active/passive). Theo tác giả, AASN thường bị nhầm với HA. - Active/passive và brown-out: khi f…
- 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
150 triệu user hoạt động; 300K QPS đọc timeline nhưng chỉ khoảng 6.000 request/giây ghi: Twitter chủ yếu là nơi tiêu thụ. 400 triệu tweet/ngày (trung bình 5K/giây, đỉnh 7K/giây, hơn 12K/giây khi có sự kiện lớn);…
- Behind the Pins: Building Analytics Bài tóm tắt · Pinterest · 2014
8/2014 Pinterest ra bản 2 của công cụ analytics cho doanh nghiệp (analytics theo domain, profile, audience; phân theo quốc gia, ứng dụng; impression, click, repin).