Tìm kiếm
40 kết quả cho “MAU”. Tìm không phân biệt dấu.
- Scaling Exact COUNT(DISTINCT) for High-Cardinality Non-Rollup Metrics Bài tóm tắt · Uber · 2026
Một lớp metric (user hoạt động theo tháng, giữ chân theo quý) phải tính chính xác và là non-rollup: không ghép được từ số theo ngày (một user hoạt động thứ Hai và thứ Tư chỉ tính một lần trong tuần). Theo quý, phải giữ…
- 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…
- 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:
- 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…
- 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".
- 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:
- 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.
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- 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…
- Query planner và hiệu năng truy vấn Chủ đề Thành viên
Database quan hệ không chạy SQL theo đúng cách nó được viết. Query planner chọn một plan (dùng index nào, join kiểu gì: nested loop, merge, hash; dừng sớm khi có LIMIT hay không) dựa trên thống kê về dữ liệu: số dòng,…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- 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.
- 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…
- 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ệ 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…
- 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,…
- 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…
- 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.
- 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ể…
- 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…
- Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) Chủ đề Thành viên
Từ 2026 các công ty bắt đầu giao cho coding agent những việc trước đây là dự án nhiều tuần: migrate hàng trăm module hay dataset, dọn feature flag, viết lại cả framework hay app. Agent viết nhanh, nhưng ba thứ không tự…
- Độ 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.
- Đổ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.
- 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:
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- 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:
- 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ì…
- 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.
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Vector search và index ANN Chủ đề Thành viên
Search ngữ nghĩa, gợi ý và RAG quy về tìm các vector (embedding vài trăm tới vài nghìn chiều) gần một vector query. Vector không có thứ tự tự nhiên, nên B-tree hay inverted index không dùng được; ở quy mô lớn phải dùng…
- Debugging the Postgres query planner Bài tóm tắt · GoCardless · 2019
…thường dưới 50 ms nay chạy rất lâu. Thay đổi chính - Query mẫu: lấy một transition theo payout id , ORDER BY id , LIMIT 1 , join payments . Có index trên payout id . - Hình dạng d…
- Modernizing Prometheus: Native Storage for Composite Types Bài tóm tắt · Prometheus · 2026
…ở production. Bối cảnh - TSDB của Prometheus từ đầu chỉ lưu mẫu nguyên thuỷ : label dạng chuỗi, giá trị float64 , timestamp int64 , không biết loại metric. Loại metric là quy ước b…
- Large-Scale Automated Dependency Analysis Across Uber's Service Mesh Bài tóm tắt · Uber · 2026
…họn đường gọi đáng đầu tư. - Vì sao không dùng tracing: lấy mẫu trace 0,01% và API có availability 99,9% thì xác suất lấy được một request lỗi là 1 trên 10 triệu; API 500 request/g…
- Our not-so-magic journey scaling low latency, multi-region services on AWS Bài tóm tắt · Atlassian · 2019
…ủa khách đều hỏng. Thay đổi chính (4 bài học "không có phép màu") 1. CQRS + DynamoDB: Catalogue Service giữ nguồn sự thật (nhất quán mạnh, yêu cầu availability và latency thấp hơn…
- Tracing Discord's Elixir Systems (Without Melting Everything) Bài tóm tắt · Discord · 2026
…1 triệu người online sẽ sinh 1 triệu span session. Lớp lấy mẫu thứ hai ở session theo kích thước fan-out: Envelope thêm trường approximate num recipients ; 1 người nhận giữ 100%,…
- How to shuffle a big dataset Bài tóm tắt · Jane Street · 2018
…tỉ lệ tín hiệu/nhiễu rất thấp nhưng rất nhiều: kiểu một tỉ mẫu huấn luyện mà nhãn chỉ hơi có xu hướng đúng. - Huấn luyện bằng SGD cần xáo trộn dữ liệu; dữ liệu không vừa RAM thì F…
- Investment Insights from Two Years of AI-Powered Postmortem Analysis Bài tóm tắt · Zalando · 2025
…a toàn bộ digest vào một prompt ra báo cáo một trang về các mẫu lặp lại. 5. Opportunity : từ mẫu ra cơ hội đầu tư. - Người kiểm ở mọi tầng: lúc phát triển, 100% output được người u…