Tìm kiếm
40 kết quả cho “message bus”. Tìm không phân biệt dấu.
- Scaling and benchmarking a critical message bus using a new indexing strategy Bài tóm tắt · Jane Street · 2026
…s://blog.janestreet.com/scaling-and-benchmarking-a-critical-message-bus/) Bối cảnh - Aria là framework và hệ messaging nội bộ (dựa trên state machine replication) xử lý nhiều terab…
- 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ả…
- Open sourcing Databus: LinkedIn's low latency change data capture system Bài tóm tắt · LinkedIn · 2013
LinkedIn có nhiều hệ lưu trữ chuyên biệt: DB OLTP nhận ghi; search index, cache, read replica phục vụ đọc. Các hệ dẫn xuất này phải theo kịp DB chính một cách đáng tin cậy và giữ thứ tự transaction.
- How Discord Stores Trillions of Messages Bài tóm tắt · Discord · 2023
…c](https://discord.com/blog/how-discord-stores-trillions-of-messages) Bối cảnh - Tiếp nối . Cụm cassandra-messages tăng từ 12 node (2017) lên 177 node, hàng nghìn tỷ tin nhắn (đầu…
- Business Continuity & Disaster Recovery in the Microservices world Bài tóm tắt · Walmart · 2019
…thái broker với trạng thái DB rất khó; dùng DB để phát lại message. - Với microservice, mỗi DB replicate độc lập , nên ở bên dự phòng, ảnh chụp chung của nhiều DB tại một thời điể…
- Getting from tested to battle-tested Bài tóm tắt · Jane Street · 2025
…định về công cụ ghi "theo Jane Street". Bối cảnh - Aria là message bus nội bộ độ trễ thấp, có thứ tự chặt và bảo đảm tin cậy, làm nền cho các team khác dựng hệ chịu lỗi (xem index…
- Introducing Espresso - LinkedIn's hot new distributed document store Bài tóm tắt · LinkedIn · 2015
…hiều phần, phần đầu là partition key (ví dụ MailboxID , rồi MessageID ); mọi document cùng partition key là một collection và được transaction khi ghi trong một request . - Router…
- Open sourcing Brooklin: Near real-time data streaming at scale Bài tóm tắt · LinkedIn · 2019
…m xuống khoảng một chục ; hàng nghìn stream, hơn 2 nghìn tỷ message/ngày . Vì sao - Một service chuyên chuyển dữ liệu gom độ phức tạp (truy cập, định dạng, bảo mật) về một chỗ để t…
- The Log: What every software engineer should know about real-time data's unifying abstraction Bài tóm tắt · LinkedIn · 2013
…ssion, search, gọi service, exception). Năm 2013: hơn 60 tỷ message ghi/ngày . - Lợi ích kiến trúc: trang job chỉ cần phát event "đã xem job"; Hadoop, chống scrape, analytics cho n…
- The LMAX Architecture Bài tóm tắt · LMAX · 2011
LMAX là sàn giao dịch phái sinh cho nhà đầu tư cá nhân (công ty mẹ là Betfair). Sàn cần latency thấp vì mỗi giao dịch làm thay đổi thị trường cho giao dịch sau; bán lẻ thì thêm nhiều người dùng. Phần lớn hoạt động đến…
- A Brief History of Scaling LinkedIn Bài tóm tắt · LinkedIn · 2015
LinkedIn ra đời năm 2003, tuần đầu có 2.700 thành viên. Năm 2015: hơn 350 triệu thành viên, hàng chục nghìn page mỗi giây, mobile chiếm hơn 50% traffic, backend chịu hàng triệu query mỗi giây.
- Building Scalable Real Time Analytics, Alerting and Anomaly Detection Architecture at Dream11 Bài tóm tắt · Dream11 · 2019
Dream11 (2019): hơn 3 TB dữ liệu/ngày, hơn 10 triệu giao dịch/ngày, 2,8 triệu người đồng thời, hàng tỉ sự kiện clickstream/ngày.
- Inside Minerva: building scalable observability for eBay's monetization platform Bài tóm tắt · eBay · 2026
Hệ tính phí (monetization) của eBay phụ thuộc khoảng 200 thuộc tính của item, seller, marketplace, campaign; eBay báo Q2/2026 có 136 triệu buyer, 2,6 tỉ listing. Một tổng toàn cục có thể trông bình thường trong khi một…
- 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.
- Hệ thống độ trễ thấp (low latency) Chủ đề Thành viên
Ở sàn giao dịch và công ty market making, mỗi giao dịch làm thay đổi thị trường cho giao dịch sau, và ai phản ứng chậm hơn thì thua. Yêu cầu không chỉ là latency trung bình thấp mà latency ổn định ở đuôi, ở thang micro…
- 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.
- Độ 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.
- 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…
- 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…
- 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:
- 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".
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- 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.
- 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…
- Scaling Security Insights: how we achieved a 10x increase in global scanning capacity Bài tóm tắt · Cloudflare · 2026
…ộ hay timeout, tiến trình crash. - Kiến trúc: scheduler đẩy message vào Kafka → fan-out tới các checker (microservice Go, mỗi loại kiểm một thứ, mỗi loại một consumer group) → chec…
- Jane Street Công ty Thành viên
Công ty giao dịch định lượng và market making, viết gần như mọi thứ bằng OCaml. Blog không kể chiến lược, nhưng kể khá nhiều về hạ tầng quanh chúng. Ở tầng công cụ, từ 2012 họ tự viết build system Jenga; năm 2014…
- Billing and Payment Platform Bài tóm tắt · Grammarly · 2023
…sure . - Chịu lỗi: transactional outbox (cập nhật DB và gửi message nguyên tử), circuit breaker, DLQ để điều tra message lỗi, xử lý message idempotent để retry không gây tác dụng p…
- How recurring network maintenance exposed 6 bugs Bài tóm tắt · Jane Street · 2026
…rong một đợt nửa triệu kết nối TCP. - Nhân vật: relay (chép message giữa các cụm Kafka) và consumer-group monitor , mỗi host chạy hàng chục cái (79 trên một host), mỗi cái giữ pool…
- 6 Event-Driven Architecture Patterns — Part 1 Bài tóm tắt · Wix · 2020
…o trình duyệt. - Không cần poll, không cần bảng trạng thái; message nằm trong Kafka nên xử lý lại được khi service restart; replication của Kafka cho phép đặt mỗi stage ở data cent…
- Utilizing Amazon DynamoDB and AWS Lambda for Asynchronous Event Publication Bài tóm tắt · Zalando · 2022
…qua REST đồng bộ; mỗi thay đổi phải phát event lên Nakadi (message bus của Zalando). - Ban đầu service ghi DynamoDB rồi gửi event ngay trong request, nên phụ thuộc cả DB lẫn bus.…
- Using an event-driven architecture to improve Jira Software responsiveness Bài tóm tắt · Atlassian · 2019
Board của Next-Gen Jira Software poll mỗi phút để lấy dữ liệu mới. Hậu quả: người khác sửa issue thì phải chờ khoảng một phút mới thấy, và phần lớn request là thừa vì không có gì đổi.
- DoorDash Công ty Thành viên
Nguồn đầu tiên của DoorDash trong wiki là bài 2022 của một thực tập sinh nghiên cứu (CMU): chaos engineering ở production không hợp với DoorDash vì khách mất đơn, nên thử fault injection có hệ thống ở mức service…
- Pushing Postgres beyond storage: scaling performance at Optiver Bài tóm tắt · Optiver · 2026
Một số database của Optiver chứa bảng nhỏ đổi rất thường xuyên, như cấu hình và dữ liệu giá, nằm thẳng trên đường đi của các hệ tự động; có thể có hàng nghìn process cần đồng bộ với chúng.
- From Always-On to On-Demand: Scaling Kafka Sinks with KEDA Bài tóm tắt · trivago · 2026
trivago dùng Kafka làm lớp vận chuyển dữ liệu giữa các hệ. Nhiều dữ liệu vào Kafka từ database qua Debezium (CDC), topic dùng log compaction nên giữ giá trị mới nhất mỗi key, như một snapshot liên tục.
- Zerodha Công ty Thành viên
Công ty môi giới chứng khoán Ấn Độ, khách tăng hơn 3 lần trong một năm (2020–2021). Theo CTO, họ trụ được nhờ các nguyên tắc lẽ thường: interface ổn định, viết lại thường xuyên (ticker viết lại ít nhất 5 lần), đóng băng…
- Allegro Công ty Thành viên
Allegro (Ba Lan) đi từ 3 developer với dữ liệu lưu trong file (1999) → scale bằng tự viết cache, connection pool, search engine bằng C trên Oracle (~2005) → framework tự chế trong cùng codebase (2008–2009, code mới vẫn…
- Atlassian Công ty Thành viên
Atlassian lên AWS năm 2016. Tenant Context Service (ánh xạ tenant → vị trí, gọi nhiều lần trong mỗi request) được tối ưu qua bốn bài học "không có phép màu": DynamoDB, load balancer, cache, client . Cùng năm 2019, nền…
- Scaling StreamHub: Transitioning from Kinesis to Kafka for 145 Billion Daily Events Bài tóm tắt · Atlassian · 2026
StreamHub là event bus của Atlassian (click, impression, API call, CDC, telemetry). Đã có trong wiki ở vai trò nền tảng cho Jira realtime năm 2019 ().
- Real-time Distributed Tracing for Website Performance and Efficiency Optimizations Bài tóm tắt · LinkedIn · 2015
…request gốc được Samza gom lại và phát thành một event trên message bus (Kafka) để phân tích realtime. Thay đổi chính - inCapacity đọc kết quả từ Samza, dựng call graph theo thời g…