Tìm kiếm
40 kết quả cho “build metadata”. Tìm không phân biệt dấu.
- Building visibility into a CI platform Bài tóm tắt · Optiver · 2026
…nh — [bài gốc](https://optiver.com/insights/technology-blog/building-visibility-into-a-ci-platform/) Bối cảnh - Lượng code qua pipeline của Optiver tăng mạnh vài năm gần đây, không…
- DataHub: A generalized metadata search & discovery tool Bài tóm tắt · LinkedIn · 2019
…s; mọi thay đổi schema bắt buộc tương thích ngược, kiểm lúc build). LinkedIn chủ yếu dùng Kafka; một job Samza đơn giản chuyển MCE thành call API. Hàng triệu MCE mỗi ngày. - Phục v…
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Building a Faster C# Driver for ScyllaDB…on our Self-Baked C#-Rust FFI Framework Bài tóm tắt · ScyllaDB · 2026
…Độ khó: Khó — [bài gốc](https://www.scylladb.com/2026/09/22/building-a-faster-c-sharp-driver/) Phần 2/2: phần 1 là . Bài nhà cung cấp; benchmark do chính họ chạy trên một máy với c…
- Building a Distributed Filesystem for Scalable Research Bài tóm tắt · Hudson River Trading · 2025
HRT nạp lượng dữ liệu lớn; researcher dùng nó để phát triển và kiểm ý tưởng, ý tưởng tốt thành chiến lược giao dịch. Phần lớn hạ tầng on-premises, trước đây trộn Lustre, NFS filer và vài hệ mã nguồn mở tự vận hành.
- Building Uber's Multi-Cloud Secrets Management Platform to Enhance Security Bài tóm tắt · Uber · 2025
…khó: Trung bình — [bài gốc](https://www.uber.com/us/en/blog/building-ubers-multi-cloud-secrets-management-platform/) Bối cảnh - Hơn 5.000 microservice, 5.000 database, hơn 500.000…
- How We Halved Go Monorepo CI Build Time Bài tóm tắt · Uber · 2022
…ttps://www.uber.com/us/en/blog/how-we-halved-go-monorepo-ci-build-time/) Bối cảnh - Monorepo Go của Uber build bằng Bazel, hơn 10 triệu target, khoảng 500.000 file. Luồng một thay…
- Building Scalable Real Time Event Processing with Kafka and Flink Bài tóm tắt · DoorDash · 2022
…âng cao — [bài gốc](https://doordash.engineering/2022/08/02/building-scalable-real-time-event-processing-with-kafka-and-flink/) Bối cảnh - Event từ service và thiết bị phải tới war…
- Building Self-driving Kafka clusters using open source components Bài tóm tắt · Slack · 2022
…· Độ khó: Trung bình — [bài gốc](https://slack.engineering/building-self-driving-kafka-clusters-using-open-source-components/) Bối cảnh - Kafka ở Slack là xương sống của Job Queue…
- 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…
- Making Order in CI/CD Mess Bài tóm tắt · Wix · 2020
…d, một project Flash và khoảng 50 developer ; cả 5 monolith build trên một server TeamCity. Deploy là thủ công: tải artifact từ TeamCity, FTP lên production, "cầu may". Production…
- Open Sourcing Screwdriver, Yahoo's Continuous Delivery Build System for Dynamic Infrastructure Bài tóm tắt · Yahoo · 2017
…tới production hoàn toàn tự động (2017). Screwdriver là hệ build và release nội bộ đã dùng khoảng 5 năm , xử lý hơn 25.000 build/ngày và hơn 12.000 commit/ngày , là điểm vào chung…
- From vendors to vanguard: Airbnb's hard-won lessons in observability ownership Bài tóm tắt · Airbnb · 2026
Airbnb ban đầu thuê ngoài observability. Theo Airbnb, khi công ty trưởng thành, nhu cầu lệch khỏi động cơ của nhà cung cấp: tính tiền theo lượng dữ liệu nạp vào, nên chi phí tăng, trong khi thêm dữ liệu không tự làm…
- The Legends of Runeterra CI/CD Pipeline Bài tóm tắt · Riot Games · 2021
…ột game (client Unity + game server). Wiki giữ phần hạ tầng build/test/deploy, bỏ qua chi tiết riêng của client. Bối cảnh - Legends of Runeterra (2021): monorepo Git LFS khoảng 100…
- Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo Bài tóm tắt · Stripe · 2026
…test unit (2026). Chạy tuần tự hết một lần mất bốn tháng ; build chạy trên một dàn worker song song khổng lồ, khoảng 50.000 build mỗi tuần , và tăng thêm khi AI làm tốc độ commit…
- Shipyard: How We Built Slack's Next-Generation EC2 Platform Bài tóm tắt · Slack · 2026
…à bảo mật) do team Compute cùng Security và Monitoring giữ, build bằng AWS Image Builder (tự dọn AMI cũ, publish ID mới vào SSM Parameter, EventBridge + Lambda kích pipeline của cá…
- A Smarter Way to Deploy Data Pipelines Bài tóm tắt · Doximity · 2025
…Docker Compose, dự định chuyển sang EKS. - Cách deploy cũ: build DAG vào image Airflow trong CI/CD, gần 20 phút mỗi lần, mỗi thay đổi của bất kỳ team nào kích hoạt rebuild toàn bộ…
- Similarity Engine at eBay Bài tóm tắt · eBay · 2023
…n vùng); hỗ trợ L2, inner product, cosine, Hamming. - Index builder phân tán: dịch vụ ingest ghi yêu cầu dựng vào kho metadata job; scheduler chia việc cho các node builder, node l…
- How Deterministic Controls Turn AI Output Into Reliable Prompt Templates Bài tóm tắt · Salesforce · 2026
…mplate. Mọi nhận định là theo Salesforce. Bối cảnh - Prompt Builder cho admin tạo prompt dùng lại với placeholder lấy dữ liệu CRM lúc chạy. Viết một template tốt cần biết dữ liệu c…
- Scaling to exabytes and beyond (Magic Pocket) Bài tóm tắt · Dropbox · 2016
…iệu ở Đức cho khách doanh nghiệp châu Âu. Bài học cho SWE - Build vs buy phụ thuộc quy mô. Dùng cloud để lớn nhanh; chỉ tự xây khi quy mô và workload đặc thù đủ bù chi phí. Dropbox…
- Dynamic alert routing with Prometheus and Alertmanager Bài tóm tắt · Loveholidays · 2021
…domain, fetch và Wayback đều lỗi). Bối cảnh - Văn hoá "you build it, you run it"; team Platform Infrastructure lo phần dùng chung (CI/CD, IaC, observability). Phần lớn service chạ…
- AWS Multi-Account Architecture with Terraform, Yeoman, and Jenkins Bài tóm tắt · Slalom Build · 2018
…· Độ khó: Trung bình — [bài gốc](https://medium.com/slalom-build/aws-multi-account-architecture-with-terraform-yeoman-and-jenkins-7fd42ddcdda8) Bài của một công ty tư vấn, mô tả c…
- MySQL sharding at Quora Bài tóm tắt · Quora · 2020
MySQL giữ câu hỏi, câu trả lời, upvote, comment: hàng chục TB (chưa kể replica), hàng trăm nghìn QPS; thêm Memcache và Redis cho đọc. Dữ liệu và QPS ghi tăng nên phải shard.
- 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…
- 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…
- 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…
- 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,…
- 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:
- 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.
- 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:
- 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:
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- 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…
- 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…
- Độ 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.
- 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…
- 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.
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…