Tìm kiếm
40 kết quả cho “Cloudflare”. Tìm không phân biệt dấu.
- Cloudflare Công ty Thành viên
Cloudflare bắt đầu bằng một cluster Postgres cfdb cho hầu hết control plane; từ 2017 các service dời dữ liệu ra dần. Đến 2022–2024 dữ liệu DNS (hàng tỷ record) được tách sang cluster riêng, sau khi mọi service đã đi qua…
- A deep dive into Cloudflare's September 12, 2025 dashboard and API outage Bài tóm tắt · Cloudflare · 2025
…2025 · 3. Quy mô lớn · Độ khó: Dễ — [bài gốc](https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/) Bối cảnh - Tenant Service (Go, chạy trên Ku…
- Redesigning Workers KV for increased availability and faster performance Bài tóm tắt · Cloudflare · 2025
…· 4. Điều chỉnh · Độ khó: Nâng cao — [bài gốc](https://blog.cloudflare.com/rearchitecting-workers-kv-for-redundancy/) Bối cảnh - Workers KV là kho KV toàn cầu: dữ liệu lưu ở storag…
- How we rebuilt Next.js with AI in one week Bài tóm tắt · Cloudflare · 2026
…4. Điều chỉnh · Độ khó: Trung bình — [bài gốc](https://blog.cloudflare.com/vinext/) Bài của nhà cung cấp, giới thiệu một dự án thử nghiệm chưa qua traffic lớn và dẫn khách về Cloud…
- Migrating billions of records: moving our active DNS database while it's in use Bài tóm tắt · Cloudflare · 2024
…· 3. Quy mô lớn · Độ khó: Nâng cao — [bài gốc](https://blog.cloudflare.com/migrating-billions-of-records-moving-our-active-dns-database-while-in-use/) Bối cảnh - Theo W3Techs (10/2…
- 500 Tbps of capacity: 16 years of scaling our global network Bài tóm tắt · Cloudflare · 2026
…2026 · 3. Quy mô lớn · Độ khó: Dễ — [bài gốc](https://blog.cloudflare.com/500-tbps-of-capacity/) Bài hồi tưởng và quảng bá nhân mốc 500 Tbps. Phần về AI crawler chỉ tóm tắt ngắn.…
- When DNSSEC goes wrong: how we responded to the .de TLD outage Bài tóm tắt · Cloudflare · 2026
…3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://blog.cloudflare.com/de-tld-outage-dnssec/) Sự cố nằm ở bên ngoài (DENIC, nhà quản lý .de ). Bài kể cách một resolver lớn giảm…
- Scaling Security Insights: how we achieved a 10x increase in global scanning capacity Bài tóm tắt · Cloudflare · 2026
…3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://blog.cloudflare.com/scaling-security-scans/) Bối cảnh - Security Insights quét định kỳ mọi account, zone, bản ghi DNS để tìm…
- Rearchitecting the Workflows control plane for the agentic era Bài tóm tắt · Cloudflare · 2026
…2026 · 3. Quy mô lớn · Độ khó: Khó — [bài gốc](https://blog.cloudflare.com/workflows-v2/) Bài của nhà cung cấp về sản phẩm của chính họ; con số giới hạn là giới hạn sản phẩm, không…
- Code Verify: verifying code authenticity on WhatsApp Web Bài tóm tắt · WhatsApp · 2022
…n sự thật: WhatsApp đưa hash mật mã của mã WhatsApp Web cho Cloudflare; extension so mã đang chạy với hash trên Cloudflare. Mỗi lần WhatsApp Web cập nhật, hash và extension tự cập…
- IPLS: Privacy-preserving storage for your WhatsApp contacts Bài tóm tắt · WhatsApp · 2024
…mới trả khoá danh bạ qua kênh mã hoá giữa client và HSM. - Cloudflare làm nhân chứng: ký mỗi epoch và root hash của AKD; HSM kiểm chữ ký bằng public key của Cloudflare. WhatsApp k…
- Moving the public Stack Overflow sites to the cloud: Part 1 Bài tóm tắt · Stack Overflow · 2025
…y và Traffic Processing Service tự viết; đưa mọi thứ ra sau Cloudflare và xử lý log bằng Snowflake , để một nơi lo cả bảo mật, cache ở edge và failover. - Kiến trúc mới: Cloudflare…
- Strengthening end-to-end encrypted backups Bài tóm tắt · WhatsApp · 2026
…key được gửi kèm phản hồi của HSM trong một gói xác thực do Cloudflare ký và Meta ký kèm ; Cloudflare giữ log kiểm toán mọi gói. - Công bố bằng chứng mỗi lần dựng đội HSM mới trên…
- HTTPS on Stack Overflow: The End of a Long Road Bài tóm tắt · Stack Overflow · 2017
…ời gian tải qua từng cấu hình, mỗi lần đo ít nhất 24 giờ. - Cloudflare: DNS nhanh hơn hẳn. Mỹ và Canada chậm hơn một chút vì thêm một hop, phần còn lại của thế giới bằng hoặc nhanh…
- 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…
- 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:
- Độ 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.
- 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ố…
- 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.
- 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ự…
- 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.
- 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á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ỡ:
- 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ả…
- 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…
- 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ế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,…
- 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…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- 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 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.
- 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…
- 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…
- 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:
- 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:
- 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:
- Behind the scenes: Redpanda Cloud's response to the GCP outage Bài tóm tắt · Redpanda · 2025
…n cầu do một bản cập nhật quota tự động vào hệ quản lý API. Cloudflare cũng bị kéo theo. - Redpanda Cloud (mô hình BYOC: cluster chạy trong tài khoản cloud của khách, Redpanda vận…
- Canva incident report: API Gateway outage Bài tóm tắt · Canva · 2024
…y; mỗi lần có hơn 100 file tĩnh mới lên S3 và được phát qua Cloudflare (tiered cache). - API Gateway là cửa vào của mọi API (xác thực, phân quyền, rate limit): Java/Netty chạy even…
- Stack Overflow Công ty Thành viên
Phản ví dụ nên đọc sớm cho niềm tin "lớn thì phải scale out". Năm 2009, với 16 triệu page view mỗi tháng, Stack Overflow chạy hai web server và một SQL Server, chạm giới hạn thì nâng RAM; theo Jeff Atwood, phần cứng rẻ…