Vì sao 70% lỗ hổng nghiêm trọng đến từ lỗi bộ nhớ trong C/C++
Số liệu từ Microsoft, Chromium, Android, các kiểu lỗi bộ nhớ (buffer overflow, use-after-free…) và vì sao code cẩn thận hơn hay sandbox không đủ.
System Design
Database, mạng, kiến trúc — giải thích bằng ví dụ. · 16 bài
Tất cả
Claude Code
Claude API
LLM & NLP
AI Agents & Skills
Tips
AI Automation
Tools
System Design
Reading
Rust chặn lỗi bộ nhớ thế nào? Ownership, borrowing và dữ liệu thật từ Android
Ba quy tắc ownership, borrowing, lifetimes; các lớp bảo vệ khác; số liệu Android (mật độ lỗ hổng giảm ~1000 lần) và giới hạn của unsafe Rust.
OWASP Top 10 cho ứng dụng LLM (2025): checklist bảo mật bắt buộc
Mười rủi ro bảo mật phổ biến nhất của ứng dụng LLM theo OWASP 2025, từ prompt injection tới unbounded consumption, kèm biện pháp cốt lõi cho từng mục.
Rate limiting với token bucket: bài học từ Stripe cho API và ứng dụng AI
Thuật toán token bucket, bốn loại limiter Stripe dùng trong production và cách áp dụng cho ứng dụng AI: giới hạn theo token, concurrency, dark launch.
Idempotency key: retry an toàn cho thanh toán, API và tool của agent
Idempotency key của Stripe và header Idempotency-Key của IETF: các tình huống server phải xử lý, retry với backoff và áp dụng cho tool của agent.
612 lần đăng nhập sai trong một giờ: đọc Event ID 4625 để phân biệt tấn công và… máy cũ
Không phải cứ log đỏ là bị tấn công. Cách SOC phân loại đăng nhập thất bại trên Windows: trường nào cần xem, khi nào là brute force, khi nào là mật khẩu cũ.
Bloom filter: vì sao “không” là chắc chắn, còn “có” chỉ là “có thể”?
Một mảng bit nhỏ trong RAM giúp RocksDB, Cassandra bỏ qua hàng loạt lần đọc đĩa vô ích — đổi lại thỉnh thoảng báo nhầm.
Bấm lưu rồi mà vẫn thấy dữ liệu cũ? Replication lag và read-your-writes
Dữ liệu không mất — chỉ là bạn đang đọc từ một bản sao chưa kịp cập nhật. Cách xử lý gọn nhất: read-your-writes.
Vì sao request đầu tiên luôn chậm hơn? TCP handshake “ăn” mất 1 RTT
Request đầu 160ms, request sau chỉ 80ms dù server trả lời tức thì. Thủ phạm là màn chào hỏi SYN / SYN-ACK / ACK.
Retry storm: vì sao exponential backoff vẫn chưa đủ, phải thêm jitter
12 client cùng retry một lúc đánh sập server 6 chỗ. Backoff quyết định chờ bao lâu, jitter quyết định server có sống hay không.
Write-Ahead Log: database báo ghi xong rồi mất điện, dữ liệu còn không?
Ack đã trả đủ 6 bản ghi nhưng bảng mới cập nhật 3 — mất điện vẫn không mất dòng nào, nhờ ghi log trước, cập nhật bảng sau.
Circuit breaker: ngắt sớm để khỏi đợi một service đã chết
Service chết mà mỗi lần gọi vẫn phải đợi 1000ms mới nhận lỗi. Circuit breaker đếm lỗi, ngắt mạch và trả lỗi ngay.
Backpressure: khi producer nhanh gấp 3, làm sao queue không tràn?
Producer đẩy 3 msg/s, consumer xử lý 1 msg/s. Không có backpressure, queue phình tới hết bộ nhớ. Có backpressure, consumer cầm nhịp.
Web xem phim gánh vạn người xem thế nào? CDN kết hợp P2P qua WebRTC
CDN chỉ gửi vài bản gốc, phần còn lại trình phát của người xem tự chuyền cho nhau — và quay về CDN ngay khi có người rời đi.
Connection pool: 45ms mở kết nối mới vs. 0,2ms mượn lại
Query chỉ 12ms mà API vẫn chậm? Thủ phạm thường là chi phí mở kết nối. Pool xoá khoản đó — nhưng khi quá tải, request phải xếp hàng.
Từ 250ms xuống 0ms: request “đi tắt” qua 4 tầng cache
Browser, CDN, Redis, Database xếp chồng. Request dừng ở tầng nào thì trả giá tới tầng đó — và mỗi lần miss, các tầng tự học.
Không tìm thấy bài phù hợp
Thử từ khoá khác hoặc bỏ bộ lọc chủ đề.
Không bỏ lỡ bài mới
Theo dõi binhAI qua RSS (Feedly, Inoreader, Slack…) để nhận bài mới ngay khi đăng.