Mời bạn thưởng thức Newsletter #72.

The Easiest Way to Build a Type Checker

Bài viết giới thiệu phương pháp kiểm tra kiểu song phương - kết hợp giữa suy luận kiểu và kiểm tra kiểu - như một cách đơn giản và thực tiễn để xây dựng các bộ kiểm tra kiểu. Tác giả cung cấp một triển khai TypeScript tối thiểu cho một ngôn ngữ nhỏ, giải thích các khái niệm cốt lõi như abstract syntax trees, xử lý ngữ cảnh, và xác thực kiểu đệ quy. Phương pháp này giúp làm rõ việc triển khai hệ thống kiểu so với các cách tiếp cận phức tạp hơn như Hindley-Milner.

Điểm chính:

• Sử dụng phương pháp kiểm tra kiểu song phương kết hợp giữa suy luận và kiểm tra kiểu
• Triển khai ví dụ bằng TypeScript cho một ngôn ngữ nhỏ
• Làm rõ các khái niệm cơ bản: AST, ngữ cảnh, xác thực kiểu đệ quy
• Đơn giản hóa việc hiểu hệ thống kiểu so với các phương pháp phức tạp hơn

Deprecation

Bài viết nói về việc loại bỏ phần mềm lỗi thời một cách có kế hoạch để giảm chi phí và độ phức tạp trong dài hạn. Google nhấn mạnh rằng “mã nguồn là nghĩa vụ, không phải tài sản”, và việc loại bỏ phần mềm thành công đòi hỏi sự sở hữu, công cụ hỗ trợ và các mốc rõ ràng. Bài viết phân biệt giữa loại bỏ theo hướng dẫn (khuyến nghị) và loại bỏ bắt buộc (được thực thi), nhấn mạnh rằng việc hỗ trợ di chuyển và ngăn chặn việc sử dụng mới là rất quan trọng. Thiết kế hệ thống với tư tưởng loại bỏ trong tương lai - như cho phép thay thế theo từng phần - sẽ làm cho việc loại bỏ dễ dàng hơn. Mặc dù có những thách thức như định luật Hyrum và sự gắn bó cảm xúc, nhưng các quy trình và công cụ có cấu trúc (ví dụ: phân tích tĩnh, thay đổi quy mô lớn) giúp quản lý các trở ngại kỹ thuật và xã hội.

Điểm chính:

• Loại bỏ phần mềm lỗi thời là cần thiết để giảm chi phí và độ phức tạp dài hạn
• Phân biệt giữa loại bỏ khuyến nghị và loại bỏ bắt buộc
• Cần hỗ trợ di chuyển và ngăn chặn việc sử dụng mới
• Thiết kế hệ thống với tư tưởng loại bỏ trong tương lai sẽ giúp việc thay thế dễ dàng hơn

16 Replication Concepts Every Software Engineer Should Know (Simple Guide for 2026)

Bài viết giải thích mười sáu khái niệm nhân bản thiết yếu - bao gồm nhân bản dựa trên người dẫn đầu, nhiều người dẫn đầu và không có người dẫn đầu; các phương pháp đồng bộ và không đồng bộ; hệ thống bỏ phiếu; độ trễ của bản sao; chuyển đổi khi gặp sự cố; nhân bản địa lý; và các kỹ thuật như sửa chữa khi đọc và chuyển tiếp gợi ý - là nền tảng cho các hệ thống phân tán đáng tin cậy và có khả năng mở rộng. Mỗi khái niệm bao gồm một ví dụ thực tế để làm rõ cách áp dụng trong thế giới thực.

Điểm chính:

• Các khái niệm nhân bản thiết yếu như nhân bản dựa trên người dẫn đầu, nhiều người dẫn đầu và không có người dẫn đầu
• Phân biệt giữa các phương pháp đồng bộ và không đồng bộ
• Hệ thống bỏ phiếu và kỹ thuật quản lý độ trễ của bản sao
• Các phương pháp chuyển đổi khi gặp sự cố và nhân bản địa lý

50 System Design Concepts for Beginners in 90 Minutes [2026 Edition]

Bài viết cung cấp cái nhìn tổng quan nhanh chóng và thực tế về 50 khái niệm thiết kế hệ thống thiết yếu cho người mới bắt đầu và ôn tập phỏng vấn. Nội dung bao gồm các nguyên tắc cốt lõi như mở rộng quy mô, định lý CAP/PACELC, ACID so với BASE, và sự đánh đổi giữa độ trễ và thông lượng. Các chủ đề quan trọng bao gồm kiến trúc hệ thống phân tán (microservices, serverless), mạng máy tính (cân bằng tải, CDN, gRPC so với REST), lưu trữ dữ liệu (phân mảnh, nhân bản, đánh chỉ mục), mẫu độ tin cậy (circuit breakers, retry, idempotency), chiến lược lưu trữ đệm, hàng đợi tin nhắn, khả năng quan sát (tracing, SLIs/SLOs), và bảo mật (OAuth, TLS, Zero Trust). Bài viết nhấn mạnh việc hiểu các sự đánh đổi và tính ứng dụng thực tế.

Điểm chính:

• 50 khái niệm thiết kế hệ thống thiết yếu cho người mới bắt đầu
• Các nguyên tắc cốt lõi như mở rộng quy mô, định lý CAP/PACELC, ACID vs BASE
• Các thành phần kiến trúc hệ thống phân tán như microservices, load balancers, CDN
• Các mẫu độ tin cậy và chiến lược lưu trữ đệm

DDD: A Toolbox, Not a Religion

Bài viết nhấn mạnh rằng Domain-Driven Design (DDD) nên được sử dụng một cách thực tiễn - như một tập hợp công cụ để giải quyết sự phức tạp của lĩnh vực nghiệp vụ thực tế, chứ không phải như một giáo điều cứng nhắc. Nội dung cho biết rằng hầu hết các sự cố phần mềm đến từ việc xử lý kém logic nghiệp vụ, chứ không phải từ những lỗi kỹ thuật. Bài viết cảnh báo về việc thiết kế quá mức và giải quyết những vấn đề tưởng tượng, thay vào đó đề xuất việc hiểu rõ lĩnh vực cốt lõi và chỉ áp dụng các mẫu DDD phù hợp. Như Miłosz nói, “DDD là về việc hiểu lĩnh vực bạn đang làm việc và sau đó mô hình hóa nó tốt trong code.”

Điểm chính:

• DDD nên được coi là một tập hợp công cụ, không phải là một giáo điều
• Hầu hết sự cố phần mềm đến từ việc xử lý logic nghiệp vụ kém, không phải lỗi kỹ thuật
• Tránh thiết kế quá mức và giải quyết vấn đề tưởng tượng
• Chỉ áp dụng các mẫu DDD phù hợp với lĩnh vực nghiệp vụ thực tế

Bonus

Images:

Videos: How Does a URL Shortener Work?