Tìm kiếm
39 kết quả cho “Edge proxy”. Tìm không phân biệt dấu.
- Meet Bandaid, the Dropbox service proxy Bài tóm tắt · Dropbox · 2018
…ở tự giảm tải cho host chậm. Liên quan - · · - Phần tiếp: - Edge proxy của Dropbox chuyển từ Nginx sang Envoy:…
- How we migrated Dropbox from Nginx to Envoy Bài tóm tắt · Dropbox · 2020
…L; goroutine mỗi request tốn bộ nhớ khi kết nối nhiều) mà ở edge thì không autoscale dễ; TLS của Go không có FIPS; không có cộng đồng ngoài Dropbox. Thay đổi chính - Hiệu năng: đo…
- Protecting our platform from spikes in usage by reducing load from the Monzo app Bài tóm tắt · Monzo · 2023
…thẻ . Thay đổi chính - Đo lãng phí trước: log 1/1000 user ở edge proxy, ghi URL kèm hash của response (không log dữ liệu nhạy cảm). Kết quả: khoảng 70% GET có một request giống hệt…
- HTTPS on Stack Overflow: The End of a Long Road Bài tóm tắt · Stack Overflow · 2017
…) Nằm ngoài các bài đánh số của series, nhưng cho thấy tầng edge (CDN, DNS, TLS) phía trước kiến trúc trong . Bối cảnh - 22/5/2017: HTTPS thành mặc định trên Stack Overflow, site c…
- How we built a secure, performant, multi-tenant cloud platform to run untrusted code Bài tóm tắt · Deno · 2024
…doanh nghiệp chạy code không tin cậy của chính user của họ (edge function của Netlify: hơn 255 triệu request/ngày, 2024). - Yêu cầu: cách ly tenant tối đa, cold start thấp, tự nhân…
- How We Built Fly Postgres Bài tóm tắt · Fly.io · 2022
…heo Fly.io". Bối cảnh - Fly.io khởi đầu (2019) là nền tảng "edge app" không có lưu trữ bền : dữ liệu thật nằm ở us-east-1 , phần chạy ở edge là cache. Khách xin database từ ngày đầ…
- 2026 World Cup: record traffic, reliability at scale Bài tóm tắt · Meta · 2026
…ter, Katran và Proxygen ở L4/L7, cân bằng tải toàn cầu chọn edge, AutoScaling cấp thêm máy. - Capacity theo vùng: đội edge làm việc với ISP hàng tháng trước giải; phần nâng cấp thà…
- 500 Tbps of capacity: 16 years of scaling our global network Bài tóm tắt · Cloudflare · 2026
2010: khởi đầu từ một văn phòng ở Palo Alto, một nhà cung cấp transit (nLayer, nay là GTT), một reverse proxy cài bằng cách đổi hai nameserver.
- 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…
- 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…
- 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.
- 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.
- 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.
- Đổ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.
- 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…
- 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:
- 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:
- 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 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:
- 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.
- 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".
- 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.
- 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:
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- Airbnb Công ty Thành viên
Airbnb chuyển từ một ứng dụng Rails khổng lồ sang SOA, và lộ ra chi phí test: deep integration test cho mọi service không scale, nên họ chuyển sang tháp test + CD có canary analysis . Năm 2025 với ba trụ sản phẩm, data…
- Fly.io Công ty Thành viên
Fly.io khởi đầu (2019) là nền tảng edge app không có lưu trữ bền, từ chối làm database hơn 300 ngày. Họ thêm volume rồi ra Fly Postgres (2021) như một "automated database": một app Postgres HA (Stolon + Consul) chạy…
- Slack Công ty Thành viên
Slack bắt đầu bằng LAMP và giữ PHP vì môi trường của nó (mỗi request trạng thái sạch, vòng lặp sửa–tải lại). Họ cải tiến dần bằng HHVM và Hack thay vì viết lại . Tầng dữ liệu đi từ MySQL active-active shard theo…
- So You Think You Can Scale? Bài tóm tắt · Railway · 2023
…thuật toán khác thì tự đặt NGINX/HAProxy. - Mạng công khai: edge là đội Envoy với control plane Go; replica mới gây cập nhật CDS và vào bảng round-robin ngay. - Replica trải trên n…
- Twitter Công ty Thành viên
Khi rời một MySQL duy nhất sang Cassandra và MySQL shard (Gizzard), thứ vỡ đầu tiên là sinh ID, dẫn tới Snowflake (64 bit, k-sorted, không phối hợp) . Sau World Cup 2010, họ nhận ra monolith Rails (~200 kỹ sư) và…
- Enhancing Bandaid load balancing with real-time backend server load information Bài tóm tắt · Dropbox · 2019
…Request của user qua GSLB (DNS) tới hơn 20 PoP, qua L4 rồi edge proxy L7, vào data center thì Bandaid định tuyến tới service. Bandaid đang dùng random N choices (N = 2) theo số re…
- Slack's Migration to a Cellular Architecture Bài tóm tắt · Slack · 2023
…vì không còn việc mới. - Thực hiện ở một chỗ: load balancer edge đều là Envoy (đã chuyển từ HAProxy), cấu hình từ control plane xDS tự viết (Rotor). Rút AZ = đổi trọng số cluster t…
- Using API Gateway for Authorization and Authentication Bài tóm tắt · Expedia · 2018
Yêu cầu duy nhất: phải có xác thực/phân quyền và không được "tĩnh" (username/password cứng gửi kèm mọi request). Đã cân nhắc Passport (phổ biến với NodeJS) và tự viết (tác giả từng làm ở dự án khác và khuyên đừng làm).
- Monzo Công ty Thành viên
Ngân hàng số với hơn 2.100 microservice và hơn 100 deploy/ngày; rollback tự động bằng Argo Rollouts trở thành mặc định cho mọi service . Để chống "stampeding herd" khi hàng triệu người mở app cùng lúc, edge proxy cắt…
- We replaced Redis with MySQL for inventory reservations, and it scaled Bài tóm tắt · Shopify · 2026
…toán (vài phút); - Claim trừ hẳn vào sổ tồn kho (inventory ledger, nguồn sự thật) khi thanh toán xong. - Sai theo hướng này thì bán trùng món cuối; sai theo hướng kia thì báo hết h…
- SoundCloud Công ty Thành viên
Năm 2013 SoundCloud rời mô hình một Public API cho mọi client, tách monolith thành microservice và khai sinh pattern BFF; đến 2021 có vài chục BFF dùng chung thư viện edge, nhưng logic tích hợp và phân quyền bị nhân bản…
- Moving the public Stack Overflow sites to the cloud: Part 1 Bài tóm tắt · Stack Overflow · 2025
…zure, và vấn đề Teams gặp sẽ còn lớn hơn ở quy mô public; - Edge và bảo mật: bỏ log HAProxy và Traffic Processing Service tự viết; đưa mọi thứ ra sau Cloudflare và xử lý log bằng S…
- Stack Overflow: The Architecture - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…n lại; - 2 nguồn điện, 2 UPS, 2 máy phát; - 4 ISP, 4 router edge; - cả hệ thống được nhân đôi ở data center thứ hai (Colorado). Scale dọc ở đây đi kèm dư thừa theo chiều ngang ở mứ…