Tìm kiếm
40 kết quả cho “bàn giao”. Tìm không phân biệt dấu.
- 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…
- Long on Research, Short on Bandwidth Bài tóm tắt · Hudson River Trading · 2026
…ww.hudsonrivertrading.com/hrtbeat/long-on-research-short-on-bandwidth/) Bối cảnh - Giao dịch của HRT dựa trên lượng tính toán nghiên cứu khổng lồ: train nhiều loại model trên nhiều…
- Building a Healthy On-Call Culture Bài tóm tắt · SoundCloud · 2021
…oặc không) lo lịch, thay đổi nhân sự, lịch lễ; nhịp ca, giờ bàn giao, cách đổi ca do cả rotation quyết, nên mỗi rotation một khác. - Rotation không chạy theo sơ đồ tổ chức: team nh…
- 5-year Evolution of Ele.me's Transaction System - Part 5 Bài tóm tắt · Ele.me · 2020
…ng vì cụm dùng chung : đơn hàng, vận đơn, merchant chỉ tách bằng virtual host. - Ngay hôm đó, trưởng phòng vận hành yêu cầu dựng cụm broadcast riêng cho đơn hàng (7 node). - Một nă…
- A monolithic architecture for our clients' hundreds of versions: how we write and support tests Bài tóm tắt · Bumble · 2019
…đưa lên production trước mọi client (app mobile, site), bọc bằng feature flag hoặc A/B test; client phát hành sau tuỳ ưu tiên, có khi nửa năm sau. Người viết backend chịu trách nhi…
- Scaling up your microservice testing with Apache Spark Bài tóm tắt · Stripe · 2026
…phân phối traffic thật trong quá khứ , đổi một luật hay một bảng giá thì kết quả đổi ở đâu. - Theo Stripe, câu hỏi này gấp hơn khi có code do AI hỗ trợ viết: thay đổi nhanh hơn, có…
- GRIT: a Protocol for Distributed Transactions across Microservices Bài tóm tắt · eBay · 2019
…và LSN) và write-set; DBTM kiểm tra OCC; LogStore được nhân bản đóng vai WAL; LogPlayer áp vào storage; storage hỗ trợ snapshot theo LSN; triển khai trên hai AZ. Bài học cho SWE -…
- 5-year Evolution of Ele.me's Transaction System - Part 3 Bài tóm tắt · Ele.me · 2020
…m giao dịch chưa từng có kỹ sư test; mọi thứ do R&D tự test bằng tay. Team framework cho rằng kỹ sư phải tự bảo đảm chất lượng. Tác giả thấy vậy là quá lý tưởng, nên chia vai: R&D…
- Scaling with common sense #2: Being future ready Bài tóm tắt · Zerodha · 2021
…chính - Viết lại có chủ đích, thường xuyên: - Kite v1 viết bằng Python, v2 là một đợt refactor lớn; - ticker (đẩy hàng chục triệu gói dữ liệu thị trường mỗi giây) được viết lại ít…
- 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ả…
- Payment Transaction Management in Microservices Bài tóm tắt · Mercari · 2019
…ỗ → thực hiện (kiểu TCC), để rollback không để lại lịch sử "bẩn". - Đối soát (reconciliation): batch đồng bộ gọi API tra cứu của service phía dưới bằng idempotency key; worker bất…
- Rest.li 2.x and a Protocol Upgrade Story Bài tóm tắt · LinkedIn · 2015
…hàng chục service. Thay đổi chính - Handshake qua D2: phiên bản giao thức cao nhất mỗi service hiểu được lưu trong cấu hình D2; client đọc rồi chọn phiên bản theo luật. Object Requ…
- Engineering operational excellence, a case of continuous improvement Bài tóm tắt · Nubank · 2023
· 2023 · 3. Quy mô lớn · Độ khó: Cơ bản — [bài gốc](https://building.nubank.com.br/engineering-operational-excellence-case-continuous-improvement/) Bài về quy trình ở một đơn vị (…
- How We Built a Logging Stack at Grab Bài tóm tắt · Grab · 2019
…t đầu POC 5 node, ước khoảng 80 node; sau hơn 400 node. Cài bằng Ansible. Ban đầu mỗi node làm cả bốn vai (ingest, coordinator, master, data) và dùng ingest node thay Logstash cho…
- 5-year Evolution of Ele.me's Transaction System - Part 2 Bài tóm tắt · Ele.me · 2020
…chuyển qua lại giữa các DB. - DDL quá đắt: thêm một cột vào bảng đơn hàng (hàng triệu đơn mỗi ngày) bị DBA đánh giá là phải dừng 3–5 giờ và cần CEO duyệt. - Một số API mở quá "thô"…
- 5-year Evolution of Ele.me's Transaction System - Part 1 Bài tóm tắt · Ele.me · 2020
…. 3. 8–9/2015: tách script và module. 4. 9/2015: tách repo bằng git filter-branch , giữ lịch sử. Lúc này vẫn deploy lẫn: "release ứng dụng độc lập" thực ra là thay một thư mục tro…
- How we rebuilt Next.js with AI in one week Bài tóm tắt · Cloudflare · 2026
…fy, Lambda) phải nắn lại output build. OpenNext làm việc đó bằng cách dịch ngược output của Next.js, nên vỡ không đoán trước giữa các phiên bản ("trò đập chuột"). API adapter của N…
- Automating Feature-Flag Cleanup at Scale with a Multi-Agent LLM System Bài tóm tắt · DoorDash · 2026
…t, logic nghiệp vụ gọi wrapper), mỗi lớp một file, liên kết bằng ngữ nghĩa chứ không bằng cú pháp; một flag Boolean đơn giản đã chạm 5–20 file kể cả test. Và giá trị đúng để thay v…
- 5-year Evolution of Ele.me's Transaction System - Part 4 Bài tóm tắt · Ele.me · 2020
…nối, hit rate, số key). Code dùng Redis cho ba việc: cache (bảng, API), distributed lock, sinh số thứ tự cho merchant. Thay đổi chính - Chuyển cụm cache thì "sốc": cụm cũ 55 GB, cụ…
- 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.
- 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.
- 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.
- 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…
- 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.
- 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:
- 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:
- 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…
- 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ỡ:
- 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".
- 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ự…
- 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,…
- 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ố…
- 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:
- 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…
- 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…
- 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…
- 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.
- 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:
- 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ể…
- 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…