Tìm kiếm
40 kết quả cho “dẫn xuất khoá”. Tìm không phân biệt dấu.
- Private by Design: How we built Firefox Sync Bài tóm tắt · Mozilla · 2018
…cung cấp tự giữ khoá thì mã hoá không chống được mối đe doạ đáng lo nhất. Thay đổi chính - Mật khẩu không bao giờ rời máy. Máy người dùng dẫn xuất passphrase thành hai giá trị khôn…
- 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…
- 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…
- 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:
- 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…
- 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:
- 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ả…
- 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ỡ:
- Mã hoá đầu cuối và hệ thống mà server không được đọc Chủ đề Thành viên
Một hệ thống bình thường giả định server thấy hết dữ liệu: server fan-out tin nhắn, lưu bản sao lưu, đồng bộ thiết bị, thu log để vận hành, chạy model, chống lạm dụng. Khi sản phẩm hứa chính nhà vận hành cũng không đọc…
- 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…
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- 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:
- 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…
- Đổ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.
- 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:
- 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:
- 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.
- Độ 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.
- 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ự…
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- 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.
- 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:
- 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ì…
- 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…
- 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…
- 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…
- Toward a Global Identity Platform Bài tóm tắt · Mercari · 2025
…ộng" chứ không xây lại). Bối cảnh - Tới 2024, nền tảng định danh của Mercari (IDaaS cho mọi dịch vụ của tập đoàn: mật khẩu, SMS OTP, đăng nhập mạng xã hội, Passkey) chỉ phục vụ ngư…
- How WhatsApp enables de-identified authenticated telemetry (DIT) Bài tóm tắt · WhatsApp · 2021
…ửi qua kết nối đã xác thực thì về bản chất vẫn gắn được với danh tính. - Bắt đầu xây từ đầu 2020 (tên cũ PrivateStats); bài viết khi đã rollout toàn cầu và đang thử nghiệm ở quy mô…
- 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…
- Apache Hudi at Uber: Engineering for Trillion-Record-Scale Data Lake Operations Bài tóm tắt · Uber · 2026
…nh thiết bị), stream có tỉ lệ update cao, và cần xử lý tăng dần thay vì tính lại cả bảng. Uber tự làm Hudi (sau thành dự án Apache): đưa ACID transaction, index + upsert nhanh, và…
- DBLog: A Generic Change-Data-Capture Framework Bài tóm tắt · Netflix · 2019
…iệu đồng bộ: một kho là nguồn sự thật (MySQL), các kho khác dẫn xuất (Elasticsearch). CDC thay cho dual write và transaction phân tán. - Transaction log có thời hạn lưu nên cần thê…
- When Bigger Instances Don't Scale Bài tóm tắt · ScyllaDB · 2026
…io kéo được tới 40 GB/s. - Hệ quả: số đo thấp làm scheduler đánh giá mỗi request đắt hơn thật, bóp nhiều hơn, nên một i7i.48xlarge chạy như một máy rẻ hơn nhiều (i7i.4xlarge). Họ k…
- How Coinbase built a governed platform for internal operations Bài tóm tắt · Coinbase · 2026
…ều cần đọc/ghi dữ liệu khách hàng, mỗi nhóm một lý do chính đáng. Để tự nhiên thì công cụ admin sinh sôi, mỗi công cụ tự làm authorization, audit và rate limit . - Với một công cụ,…
- crates.io security incident: improperly stored session cookies Bài tóm tắt · Rust · 2025
…phát hiện giá trị cookie cargo session (giá trị đã ký, định danh user đang đăng nhập, đủ để giả danh user đó) bị gửi kèm payload sự kiện lỗi lên dịch vụ giám sát lỗi Sentry mỗi khi…
- How PayPal Uses Real-time Graph Database and Graph Analysis to Fight Fraud Bài tóm tắt · PayPal · 2021
…ngắn. Bối cảnh - 2021: hơn 400 triệu người dùng và merchant đang hoạt động, vài nghìn giao dịch thanh toán mỗi giây. Quan hệ giữa tài khoản (cùng IP, cùng thiết bị, cùng hộ gia đìn…
- From Static Rate Limiting to Adaptive Traffic Management in Airbnb's Key-Value Store Bài tóm tắt · Airbnb · 2026
…Bối cảnh - Mussel là kho key-value multi-tenant cho dữ liệu dẫn xuất. Mọi lượt tra cứu (search, hỗ trợ khách...) cuối cùng đều chạm vào nó. Mussel là một fleet dispatcher stateless…
- Osprey: Open Sourcing our Rule Engine Bài tóm tắt · Discord · 2026
…tắt ngắn, giữ phần kiến trúc. Bối cảnh - Discord cần một hệ đánh giá hoạt động của user theo thời gian thực để phát hiện lạm dụng: xử lý hàng nghìn event mỗi giây, cho team viết lu…
- Search Architecture Bài tóm tắt · Instagram · 2015
…(sự kiện like kèm cả object Media, người like, chủ ảnh, có đang follow không), gửi qua kênh pub/sub bất đồng bộ Firehose (dựng trên Scribe). Consumer như search lọc sự kiện liên q…
- The Log: What every software engineer should know about real-time data's unifying abstraction Bài tóm tắt · LinkedIn · 2013
…chạm giới hạn của một database tập trung , chuyển sang một danh mục hệ phân tán chuyên biệt: search, social graph, Voldemort (key-value), Espresso (document), recommendation, OLAP…