Tìm kiếm
40 kết quả cho “Session log”. Tìm không phân biệt dấu.
- Session revocations at scale Bài tóm tắt · Canva · 2026
…khó: Khó — [bài gốc](https://www.canva.dev/blog/engineering/session-revocations-at-scale/) Bối cảnh - Session của hàng trăm triệu người dùng nằm trong cookie mã hoá (user ID, quyền…
- crates.io security incident: improperly stored session cookies Bài tóm tắt · Rust · 2025
…c](https://blog.rust-lang.org/2025/04/11/crates-io-security-session-cookies/) Chuyện gì đã xảy ra - Đội crates.io phát hiện giá trị cookie cargo session (giá trị đã ký, định danh u…
- 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…
- Scaling Managed Agents: Decoupling the brain from the hands Bài tóm tắt · Anthropic · 2026
…ần cứng thành process , file . - Ba thành phần được ảo hoá: session (log chỉ-ghi-thêm mọi chuyện đã xảy ra), harness ("bộ não": model + vòng lặp), sandbox ("đôi tay": môi trường ch…
- Building Slack's Anomaly Event Response Bài tóm tắt · Slack · 2025
…là ngày hoặc giờ. Thay đổi chính - AER tự động chấm dứt mọi session của user khi phát hiện hành vi rủi ro cao; mục tiêu rút khoảng cách xuống vài phút. - Bộ phát hiện chọn theo độ…
- What we learned from an iOS app OOMs incident Bài tóm tắt · Pinterest · 2021
…(CFUR) giảm từ 99% xuống 96% . - App gọi REST API qua NSURLSession ; phần lớn endpoint đã chạy HTTP/2 nhiều năm, vài endpoint còn sót. Khi bật HTTP/2 cho một số endpoint đó, OOM t…
- What Powers Instagram: Hundreds of Instances, Dozens of Technologies Bài tóm tắt · Instagram · 2011
…rên S3 + CloudFront. - Redis cho feed chính, activity feed, session. - Solr cho geo-search sau khi Postgres đã shard. - 6 máy Memcached. - Bất đồng bộ: Gearman với ~200 worker Pyth…
- Lessons from Building Observability Tools at Netflix Bài tóm tắt · Netflix · 2018
…ái niệm (mọi request của một phiên phát dùng chung playback session ID), và analyzer trả lời câu hỏi hay gặp (vì sao phiên này không được 4K hay HDR). Họ bắt đầu gom cụm log lỗi bằ…
- Building a Faster C# Driver for ScyllaDB…on our Self-Baked C#-Rust FFI Framework Bài tóm tắt · ScyllaDB · 2026
…n trúc hai driver lệch nhau: C có đối tượng Cluster quản lý session và kết nối điều khiển (cho phép đọc metadata trước khi có session), Rust thì không. Họ dựng một kiến trúc lai gi…
- Maxjourney: Pushing Discord's Limits with a Million+ Online Users in a Single Server Bài tóm tắt · Discord · 2023
…iểm định tuyến trung tâm; mỗi client kết nối là một process session. Guild fan-out mọi hành động tới session, session đẩy qua websocket. - Công việc tăng theo bình phương số người…
- The LMAX Architecture Bài tóm tắt · LMAX · 2011
…ch trong một micro giây. - Loại bỏ cách truyền thống (nhiều session phối hợp qua một DB giao dịch): theo kinh nghiệm Betfair, giữ hiệu năng cho một DB cực nóng đã đòi nhiều "hành đ…
- How we modified our infrastructure to deploy an EU data center Bài tóm tắt · Asana · 2020
…n DB , hiếm khi phải gọi master shard. - Ràng buộc mới: mỗi session chỉ truy cập master shard và đúng một domain shard , nên một session chỉ nói chuyện với một vùng. Code cũ vi phạ…
- How Discord Reduced Websocket Traffic by 40% Bài tóm tắt · Discord · 2024
…lớn ở chỗ khác (snapshot → delta). Liên quan - · - Passive session ra đời ở:…
- Engineering the agentic SDLC Bài tóm tắt · Optiver · 2026
SDLC truyền thống giả định người lái; bước đầu tự nhiên là dùng AI để tăng tốc quy trình cũ. Optiver thử giả định ngược lại: agent làm phần lớn việc, người dẫn hướng và tinh chỉnh. Họ chia khung làm ba tầng: workflow…
- Courier: Dropbox migration to gRPC Bài tóm tắt · Dropbox · 2019
…48 sang ECDSA P-256 cho ký, sửa gRPC-core/gRPC-python để có session resumption . Mã hoá đối xứng rẻ (khoảng 40 Gbps một core) nên khi tốc độ mã hoá ngang tốc độ memcpy thì phải giả…
- PlentyOfFish Architecture Bài tóm tắt · PlentyOfFish · 2007
…d balancer phần cứng vì IIS giới hạn 64.000 kết nối; sticky session theo user thay vì lưu session ngoài (máy chết thì user đăng nhập lại; chấp nhận được với site hẹn hò). Không dùn…
- Scaling Verify with Wallet for Identity Verification at Uber Bài tóm tắt · Uber · 2026
…i chứng chỉ truy cập của app, server giải mã payload CBOR . Session transcript gắn response với đúng giao dịch (nonce, định danh client, hash khoá công khai) để chống replay. Ba bư…
- Centrifuge: a reliable system for delivering billions of events per day Bài tóm tắt · Segment · 2018
…i cho mỗi DB: mỗi Director (Go) giữ độc quyền một JobDB qua session Consul, cache toàn bộ job trong RAM và tự lo invalidation không cần phối hợp; chỉ đọc DB khi khôi phục sau lỗi.…
- AI Agent Observability: Making Silent Production Failures Visible and Actionable Bài tóm tắt · Salesforce · 2026
Agentforce Health Monitoring (AHM) giúp người dựng agent và người vận hành của khách phát hiện sự cố về khả dụng của agent ở production, điều tra, và định tuyến alert theo quy trình của tổ chức họ.
- Running a Software Factory Efficiently at Uber Scale Bài tóm tắt · Uber · 2026
AI có mặt ở mọi pha phát triển phần mềm ở Uber (2026): hơn 70% pull request được ghi cho agent chạy local hoặc cloud; engineer đã viết hơn 3.600 agent skill, hơn 30.000 lượt chạy skill mỗi ngày. Ngày càng nhiều phiên do…
- 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ỡ:
- 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:
- 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…
- 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:
- 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…
- 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.
- 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.
- 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…
- 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".
- 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.
- 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…
- 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.
- 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:
- 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.
- Độ 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.
- 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…
- Netflix Công ty Thành viên
Sự cố hỏng DB năm 2008 dẫn tới 7 năm lên AWS theo hướng cloud-native . Bài kiểm tra lớn đầu tiên là sự cố AWS US-East năm 2011: kiến trúc stateless, nhiều zone, fallback chịu được, nhưng rút khỏi zone phải làm tay. Từ…