Databases on miti99

Newsletter #85

Sat, 28 Feb 2026 00:00:00 +0700

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

How I Use Claude Code

Tác giả chia sẻ quy trình làm việc hiệu quả khi sử dụng Claude Code trong 9 tháng qua, với một nguyên tắc cốt lõi: không bao giờ để Claude viết mã cho đến khi bạn đã xem xét và phê duyệt một kế hoạch viết tay. Phương pháp này tách biệt hai giai đoạn tư duy và thực thi, giúp ngăn chặn sự lãng phí công sức, giữ người lập trình kiểm soát các quyết định kiến trúc, và tạo ra kết quả tốt hơn nhiều.

Quy trình được chia thành ba giai đoạn chính. Giai đoạn Nghiên cứu bắt đầu bằng việc yêu cầu Claude đọc sâu phần cơ sở mã liên quan và viết báo cáo chi tiết vào tệp research.md. Giai đoạn Lập kế hoạch tạo ra tệp plan.md với hướng dẫn triển khai cụ thể. Điều thú vị nhất là Vòng lặp ghi chú (Annotation Cycle) - tác giả mở tệp kế hoạch trong trình soạn thảo và thêm ghi chú trực tiếp vào tài liệu để sửa các giả định sai, từ chối phương án không phù hợp, hoặc bổ sung kiến thức lĩnh vực. Quá trình này lặp lại 1-6 lần cho đến khi kế hoạch hoàn chỉnh.

Giai đoạn Triển khai diễn ra sau khi mọi quyết định đã được xác nhận, với câu lệnh chuẩn yêu cầu Claude thực thi toàn bộ kế hoạch, đánh dấu hoàn thành từng tác vụ, chạy kiểm tra kiểu liên tục, và không dừng cho đến khi tất cả hoàn thành. Tác giả nhấn mạnh việc thực thi nên trở nên “nhàm chán” - công việc sáng tạo đã diễn ra trong các vòng lặp ghi chú, và khi kế hoạch đúng, thực thi phải thẳng tiến. Cách tiếp cận này loại triệt để các giả định sai được xây đắp chồng chất trong 15 phút, giúp người lập trình luôn ngồi ghế lái và đưa ra các quyết định quan trọng.

Điểm chính:

Tách biệt tư duy và thực thi: luôn viết kế hoạch trước khi viết mã
Vòng lặp ghi chú: thêm ghi chú trực tiếp vào kế hoạch để tinh chỉnh và sửa lỗi sai
Tệp markdown làm trạng thái chia sẻ: giúp duy trì ngữ cảnh và quyết định
Chạy trong một phiên dài: tận dụng tích lũy ngữ cảnh thay vì chia nhỏ phiên
Giữ quyền kiểm soát: người lập trình đưa ra quyết định, Claude thực thi cơ khí

Next-Generation DB Ingestion at Pinterest

Pinterest chia sẻ hành trình xây dựng khung làm việc nhập liệu cơ sở dữ liệu thế hệ mới dựa trên Change Data Capture (CDC), thay thế hệ thống batch cũ kỹ gặp nhiều hạn chế. Hệ thống cũ có độ trễ dữ liệu cao (trên 24 giờ), xử lý kém hiệu quả do chạy full-table batch hàng ngày dù thay đổi thực tế dưới 5%, thiếu hỗ trợ xóa theo hàng cho tuân thủ, và phức tạp trong vận hành với nhiều quy trình độc lập.

Giải pháp mới là khung làm việc thống nhất sử dụng Debezium/TiCDC, Kafka, Flink, Spark và Iceberg, cung cấp dữ liệu trong vài phút thay vì ngày, chỉ xử lý các bản ghi thay đổi để tiết kiệm chi phí, hỗ trợ xóa theo hàng và xử lý tăng dần. Kiến trúc gồm ba lớp chính: lớp CDC bắt thay đổi cơ sở dữ liệu với độ trễ dưới 1 giây và ghi vào Kafka; lớp Streaming (Flink) xử lý sự kiện gần thời gian thực vào bảng CDC Iceberg trên S3; lớp Batch (Spark) định kỳ lấy thay đổi từ bảng CDC và dùng Merge Into để upsert vào bảng Iceberg cơ sở.

Bài viết chi tiết nhiều tối ưu hóa quan trọng. Phân vùng bảng cơ sở bằng băm của khóa chính sử dụng hàm bucket() giúp phân tán đều bản ghi và cải thiện hiệu suất upsert. Với vấn đề tệp nhỏ, thiết lập WRITE DISTRIBUTED BY PARTITION giảm số lượng tệp nhỏ và cải thiện hiệu suất. Bucket Join cho các bảng lớn, sử dụng bảng tạm trung gian để bỏ qua toàn bộ thao tác trộn của bảng cơ sở, giúp giảm 40%+ chi phí tính toán và độ trễ đáng kể. Pinterest chọn Merge-on-Read (MOR) thay vì Copy-on-Write (COW) vì chi phí lưu trữ của COW cao hơn nhiều.

Điểm chính:

Từ batch sang CDC: giảm độ trễ từ 24 giờ xuống 15-60 phút
Kiến trúc hai bảng: bảng CDC (append-only, <5 phút) và bảng cơ sở (snapshot, 15-60 phút)
Tối ưu hóa phân vùng bucket: phân tán đều bản ghi, upsert song song hiệu quả
Bucket Join với bảng tạm: giảm 40%+ chi phí tính toán
Merge-on-Read: ưu tiên vì chi phí lưu trữ thấp hơn Copy-on-Write

Thank you, AI

Một câu chuyện ngắn về hậu quả không mong muốn của AI scrapers. Tác giả đã chạy máy chủ git tự lưu trữ công khai từ năm 2011 (và CVS trước đó), nhưng buộc phải đóng cửa sau khi các bot AI tấn công giao diện cgit với hàng loạt yêu cầu vô bổ đến mức “gây chết” máy chủ. Thay vì chiến đấu với scrapers, tác giả quyết định chuyển tất cả kho lưu trữ sang GitLab và GitHub - hầu hết đã có bản sao sẵn ở đó.

Điều đáng chú ý là ngay cả khi dịch vụ git đã bị tắt, AI scrapers vẫn tiếp tục tấn công. Hàng triệu phản hồi 404 không đủ để thuyết phục bot rằng dịch vụ cgit không còn tồn tại, và các tệp nhật ký đã lấp đầy đĩa nhanh đến mức logrotate không kịp xử lý, gây ra một lần sự cố khác. Tác giả đã di chuyển blog từ WordPress sang Jekyll từ 2018 nên là các trang tĩnh, ít bị ảnh hưởng hơn, nhưng vẫn phải điều chỉnh cấu hình logrotate để ngăn vấn đề tương tự. Câu chuyện này là lời nhắc nhở về tác động của AI scrapers đối với các dịch vụ tự lưu trữ quy mô nhỏ.

Điểm chính:

AI scrapers tấn công máy chủ git tự lưu trữ đến mức không thể phục hồi
Chuyển sang GitLab/GitHub thay vì xây dựng lại máy chủ
Scrapers vẫn tiếp tục gửi yêu cầu sau khi dịch vụ tắt, lấp đầy đĩa bằng nhật ký
Trang tĩnh (Jekyll) an toàn hơn trang động (WordPress)

Java UI in 2026: The Complete Guide

Hướng dẫn toàn diện về các framework UI Java năm 2026, bao phủ web, desktop, mobile và terminal interfaces. Tác giả khẳng định đây không phải là các dự án lỗi thời (legacy) mà là công nghệ production-ready, được bảo trì actively và đang chạy tại các doanh nghiệp lớn, phục vụ hàng triệu người dùng trên toàn thế giới.

Bài viết phân loại frameworks theo 4 nhóm chính. Web UI có Vaadin (server-driven, viết toàn bộ bằng Java), Apache Wicket (component-oriented từ 2004), TeaVM (biên dịch Java bytecode sang JavaScript/WebAssembly), HTMX + Spring Boot (hypermedia-driven), j2html (type-safe HTML builder) và PrimeFaces (thư viện 100+ component cho Jakarta EE). Desktop UI có JavaFX (tiêu chuẩn hiện đại với CSS styling), JCEF (wrapper Chromium), Swing với FlatLaf (được làm mới), và Eclipse RCP/NetBeans Platform cho ứng dụng mô-đun phức tạp. Mobile có Codename One (write-once-run-anywhere, cloud builds, không cần Mac cho iOS) và Gluon Mobile (mở rộng JavaFX với GraalVM). Terminal có JLine (console input) và Lanterna (GUI toolkit cho terminal).

Insights quan trọng: Java UI ecosystem mạnh mẽ và production-ready, không còn là legacy technology. Frameworks hiện đại tập trung vào developer experience, type safety và native performance. Java vẫn là lựa chọn hàng đầu cho enterprise applications nhờ tính ổn định và hiệu năng, với sự phân biệt rõ ràng giữa server-driven (Vaadin), client-side (TeaVM) và hybrid approaches.

Điểm chính:

Java UI production-ready: không phải legacy, đang chạy tại doanh nghiệp lớn
Web UI đa dạng: từ server-driven (Vaadin) đến client-side (TeaVM)
Desktop hiện đại: JavaFX là tiêu chuẩn, Swing được hồi sinh với FlatLaf
Mobile thực tế: Codename One và Gluon Mobile giúp viết Java cho iOS/Android
Terminal UI: JLine và Lanterna cho console applications

Java Full Stack Development in 2026

Tác giả chia sẻ kinh nghiệm chuyển đổi ứng dụng www.scanii.com từ stack webpack+TypeScript+Spring Boot truyền thống sang kiến trúc đơn giản hơn với server-side rendering, đạt được nhiều cải thiện đáng kể: codebase được hợp nhất với đơn giản “Run” target trong IntelliJ, thời gian build frontend giảm xuống 0 với tự động reload, partial page rendering như SPA nhưng vẫn có thể dùng React nếu muốn, 100 điểm Lighthouse performance score, và dễ debug hơn không cần source maps hay transpilation.

Ba bước chính để di chuyển: Chọn template engine (tác giả dùng JTE vì có toàn bộ JDK trong template và view model map tốt với Page objects), loại bỏ bundler và sử dụng importmaps (chuẩn HTML) thay vì webpack/TypeScript, kết hợp với webjars để serve dependencies trực tiếp từ Spring Boot mà không cần CDN bên thứ ba. Cung cấp tính tương tác với Turbo và Stimulus từ Hotwire.dev (theo hướng dẫn của Rails) để đạt automatic partial page updates và familiar MVC framework cho JavaScript vẫn cần thiết.

Pain points và giải pháp: Thiếu HOT Reloading được giải quyết bằng logic tối giản client-side (poll server changes) và server-side (monitor filesystem changes), nhanh hơn solution frontend trước đó. CSRF protection trở nên phức tạp với server-side rendering vì Spring Security relied on random tokens trong mỗi form, gây vấn đề với Turbo page caching. Tác giả build custom CSRF filter dựa trên header Sec-Fetch-Site, không cần tokens trong templates hay issues với partial page reloads.

Điểm chính:

Server-side rendering: codebase hợp nhất, build time 0, debug dễ dàng hơn
Importmaps thay vì bundler: theo chuẩn HTML, kết hợp webjars serve dependencies từ Spring Boot
Turbo + Stimulus: partial page updates như SPA mà không cần React
CSRF custom filter: dùng Sec-Fetch-Site header thay vì tokens
Small teams: phù hợp cho team generalist thay vì specialized teams

Sharding Databases with Spring Boot: Patterns, Pitfalls, and Failure Modes

Hướng dẫn chi tiết về triển khai sharding database sử dụng Spring Boot - kỹ thuật phân tán dữ liệu quan trọng để giải quyết vấn đề hiệu quả và khả năng mở rộng của các ứng dụng lớn. Bài viết đề cập các pattern chính: Sharding theo chiều ngang (phân tán dữ liệu dựa trên trường cụ thể như user ID đến nhiều database/table khác nhau), Sharding theo chiều dọc (phân tán theo logic kinh doanh, mỗi shard xử lý nhóm chức năng riêng), và Sharding logic sử dụng thuật toán hash modulo để định tuyến dữ liệu đến shard phù hợp.

Các vấn đề và lỗi phổ biến khi sharding: SQL không tương thích vì các truy vấn hoạt động tốt trên database đơn có thể lỗi trên hệ thống sharding, distributed transaction dựa trên XA không đảm bảo hiệu quả trong môi trường cao đồng thời, độ phức tạp quản lý tăng lên khi phải xác định database/table để truy xuất dữ liệu, và thách thức truy vấn chéo khi cần kết hợp giữa các shard yêu cầu tổng hợp dữ liệu. Giới hạn số lượng shard quan trọng vì quá nhiều shard dẫn đến hiệu suất kém do tổng hợp dữ liệu.

Khuyến nghị và thực hành tốt nhất: Ưu tiên transaction đơn database, có thể sử dụng transaction cục bộ trong cùng database để tránh distributed transaction. Cẩn thận với phụ thuộc phiên bản vì lỗi tương thích giữa Spring Boot và ShardingSphere thường gặp. Cấu hình minh bạch sử dụng Spring Boot Starter để quản lý cấu hình sharding hiệu quả. Theo dõi hiệu suất để đảm bảo việc sharding thực sự cải thiện hiệu suất không gây thêm độ trễ.

Điểm chính:

Ba pattern sharding: ngang (theo trường), dọc (theo logic), logic (hash modulo)
Pitfalls phổ biến: SQL không tương thích, XA transaction kém hiệu quả, độ phức tạp tăng
Cross-shard queries: thách thức tổng hợp dữ liệu từ nhiều shard
Giới hạn shard: quá nhiều shard làm giảm hiệu suất do tổng hợp
Transaction cục bộ: ưu tiên single-DB transaction thay vì distributed

Go Made Me Fast, Rust Made Me Care, AWS Made Me Pay

Bài viết thảo luận về lựa chọn ngôn ngữ lập trình cho kiến trúc cloud, tập trung vào sự đánh đổi giữa Go và Rust khi hệ thống phát triển từ “hợp lý” thành “đắt tiền”. Tác giả chia sẻ kinh nghiệm thực tế về sự khác biệt giữa hai ngôn ngữ trong bối cảnh AWS, nơi chi phí được tính theo chu kỳ CPU, lượng bộ nhớ và lưu lượng mạng.

Go giúp phát triển nhanh với mô hình đồng trình đơn giản, thư viện chuẩn mạnh mẽ và dự đoán được. Tuy nhiên bộ thu gom rác (GC) của Go trở thành điểm yếu khi hệ thống mở rộng - nó yêu cầu bộ nhớ phụ, tiêu tốn CPU và gây độ trễ không đáng tin cậy. Rust không phải là phép màu tốc độ, mà buộc nhà phát triển phải đối mặt với các vấn đề cấp thấp như phân bổ bộ nhớ, sở hữu dữ liệu và hành vi cache. Điều này dẫn đến thiết kế hệ thống hiệu quả hơn với bộ nhớ ổn định, độ trễ nhất quán và mật độ container cao hơn.

AWS đóng vai trò như thực tế khắc nghiệt - nó không quan tâm đến trải nghiệm nhà phát triển, chỉ tính phí theo tài nguyên sử dụng. Sự khác biệt chi phí không nằm ở ngôn ngữ mà ở hiệu quả sử dụng tài nguyên. Bài học quan trọng: Go vẫn hoàn hảo cho API và logic nghiệp vụ, trong khi Rust phù hợp cho đường dẫn dữ liệu cao throughput. Điểm ngọt ngào là sử dụng cả hai ngôn ngữ một cách có chủ đích, với Rust trong các phần nhạy cảm hiệu năng để tối ưu hóa hóa đơn AWS.

Điểm chính:

Go nhanh phát triển: GC đơn giản, thư viện mạnh, nhưng GC overhead khi scale
Rust ép tư duy: đối mặt vấn đề cấp thấp, thiết kế hiệu quả hơn, bộ nhớ ổn định
AWS tính phí thực tế: không quan tâm DX, chỉ tính CPU/memory/network
Hybrid approach: Go cho API/business logic, Rust cho high-throughput data paths
Sweet spot: Rust tối ưu phần nhạy cảm hiệu năng để giảm hóa đơn AWS

The Cloud Is Not Your Computer: Why Go and Rust Developers Secretly Miss the Monolith

Bài viết phân tích sự thật rằng đám mây không phải là máy tính của bạn mà là một cuộc đàm phán phức tạp. Tác giả trải nghiệm qua nhiều nền tảng từ bare metal đến AWS và nhận ra rằng dù viết code Go hay Rust cảm thấy kiểm soát được thì khi triển khai lên cloud, mọi thứ trở nên bất định. Sự khác biệt chính giữa cloud và máy tính cục bộ là: máy tính cục bộ cho cảm giác kiểm soát trực tiếp, còn cloud khiến bạn đang thuê xác suất chứ không phải chạy phần mềm.

Go - ngôn ngữ của những người lạc quan - thừa nhận thất bại như một giá trị, trong khi Rust - ngôn ngữ của những người kiểm soát cực đoan - đòi hỏi sự chính xác biên dịch. Các nhà phát triển trầm trồ kiến trúc monolith vì chúng có thể dự đoán, triển khai và hiểu được. Khi có lỗi, họ chỉ cần SSH vào một máy, kiểm tra log và sửa. Ngày nay họ phải mở nhiều công cụ giám sát khác nhau mà vẫn không hiểu tại sao 503 xảy ra.

Bài học rút ra là Go và Rust đang phát triển mạnh trong cloud vì chúng là ngôn ngữ trung thực trong môi trường không trung thực. Go đón nhận thất bại như một giá trị, Rust thực thi sự chính xác tại thời điểm biên dịch. Đám mây là hỗn loạn, còn Go và Rust là kỷ luật. Sự căng thẳng đó chính là lý do chúng thuộc về nhau. Cloud là về quản lý sự bất định, không phải kiểm soát - và Go, Rust là công cụ tốt nhất để điều hướng sự bất định đó.

Điểm chính:

Cloud vs máy tính: cloud là thuê xác suất, không phải chạy phần mềm
Monolith đáng nhớ: dự đoán được, SSH vào máy để debug, dễ hiểu
Microservices chaos: nhiều công cụ giám sát, vẫn không hiểu tại sao 503
Go lạc quan: thừa nhận thất bại như giá trị, handle gracefully
Rust kiểm soát: thực thi chính xác tại compile, catch errors sớm

Bonus

Hình ảnh:

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #80

Tue, 03 Feb 2026 00:00:00 +0700

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

Thư Mục Kỹ Năng Của Tác Nhân

Skills.sh là một hệ sinh thái mở dành cho các kỹ năng của tác nhân trí tuệ nhân tạo, nơi tập hợp hàng ngàn kỹ năng có thể tái sử dụng để nâng cao khả năng của các tác nhân trí tuệ nhân tạo. Mỗi kỹ năng là một khả năng chuyên biệt có thể được cài đặt chỉ với một lệnh duy nhất, giúp các tác nhân trí tuệ nhân tạo tiếp cận các kiến thức quy trình chuẩn hóa.

Trang web cung cấp bảng xếp hạng các kỹ năng phổ biến nhất với số lần cài đặt thực tế, cho phép người dùng dễ dàng tìm kiếm và khám phá các kỹ năng phù hợp với nhu cầu của mình. Các kỹ năng hàng đầu bao gồm các công cụ tìm kiếm kỹ năng, hướng dẫn tốt nhất cho React và Next.js, các quy trình thiết kế web, và nhiều kỹ năng khác liên quan đến phát triển giao diện, máy chủ, kiểm thử, và vận hành.

Điểm đặc biệt của hệ sinh thái này là tính cộng đồng và khả năng mở rộng - bất kỳ ai cũng có thể đóng góp và chia sẻ các kỹ năng của mình, tạo nên một kho tàng kiến thức tập thể liên tục phát triển. Các tác nhân có thể tận dụng các kỹ năng này để thực hiện các tác vụ phức tạp một cách chuyên nghiệp và hiệu quả hơn, từ viết mã, kiểm thử, đến triển khai và vận hành.

Điểm chính:

Kho kỹ năng mở với hàng ngàn kỹ năng có thể cài đặt bằng một lệnh
Bảng xếp hạng theo số lần cài đặt và xu hướng 24 giờ
Hỗ trợ nhiều loại tác nhân và khung làm việc phổ biến
Cộng đồng sôi nổi với các kỹ năng từ Vercel, Anthropic, Expo, Supabase

Kết quả Khảo sát Nhà phát triển Go 2025

Go Team đã công bố kết quả khảo sát nhà phát triển Go năm 2025 với dữ liệu từ 5.379 người tham gia. Khảo sát lần này tập trung vào cảm nhận của nhà phát triển về ngôn ngữ Go, các trường hợp sử dụng, thách thức và môi trường phát triển.

Ba phát hiện quan trọng nhất từ khảo sát: các nhà phát triển Go cần hỗ trợ về việc xác định và áp dụng các phương pháp tốt nhất, tận dụng tối đa thư viện chuẩn, và mở rộng ngôn ngữ với các tính năng hiện đại hơn. Hầu hết các nhà phát triển Go hiện đang sử dụng công cụ phát triển hỗ trợ bởi trí tuệ nhân tạo khi tìm kiếm thông tin hoặc viết mã lặp lại, nhưng mức độ hài lòng chỉ ở mức trung bình do lo ngại về chất lượng mã nguồn. Một tỷ lệ đáng ngạc nhiên là số người tham gia cho biết họ thường xuyên cần xem lại tài liệu cho các lệnh go cơ bản như go build, go run, và go mod, cho thấy có chỗ cải thiện lớn cho hệ thống trợ giúp của lệnh go.

Về mức độ hài lòng, 91% người tham gia cho biết họ hài lòng khi làm việc với Go, trong đó gần 2/3 là “rất hài lòng”. Con số này đã ổn định kể từ năm 2019. Các trường hợp sử dụng chính vẫn là dòng lệnh và dịch vụ ứng dụng lập trình, với 55% người tham gia xây dựng cả hai. Hơn 1/3 xây dựng công cụ cơ sở hạ tầng đám mây, và 11% làm việc với các mô hình máy học, công cụ, hoặc tác nhân.

Điểm chính:

91% nhà phát triển Go hài lòng với ngôn ngữ, mức ổn định kể từ năm 2019
53% người tham gia sử dụng công cụ trí tuệ nhân tạo hàng ngày nhưng chỉ 13% “rất hài lòng”
Thách thức lớn nhất: tuân thủ điển lệ Go, thiếu tính năng từ ngôn ngữ khác, tìm mô-đun tin cậy
60% phát triển trên macOS, 58% trên Linux, 96% triển khai lên hệ thống dựa trên Linux

Một Đánh Giá Trung Thực Về Go

Bài viết này chia sẻ trải nghiệm cá nhân của tác giả sau vài tháng làm việc với Go, với cái nhìn từ một người có nền tảng Rust. Tác giả phân tích những điểm mạnh và điểm yếu của ngôn ngữ này từ góc nhìn thực tế.

Về điểm mạnh, Go làm rất tốt việc xử lý đồng thời với goroutines và channels được tích hợp sâu vào ngôn ngữ, tránh được vấn đề “colored functions” mà nhiều ngôn ngữ khác gặp phải. Hệ thống kiểu đơn giản, không cho phép kế thừa phức tạp, với struct embedding là một tính năng thú vị. Các giao diện trong Go không cần được triển khai một cách rõ ràng, giúp giảm mã soạn sẵn. Cú pháp của Go cũng được đánh giá là gọn gàng, với quy tắc khả kiến dựa trên chữ hoa chữ thường rất trực quan.

Tuy nhiên, tác giả cũng chỉ ra những điểm yếu đáng kể. Thiếu kiểu liệt kê thực sự là một vấn đề lớn - giải pháp thay thế với hằng số và iota không đảm bảo an toàn kiểu và không có kiểm tra đầy đủ. Go cũng thiếu bất biến đúng đắn: hằng số chỉ hoạt động với giá trị thời gian biên dịch, còn biến bình thường thì có thể bị biến đổi bất cứ lúc nào. Hệ thống xử lý lỗi tuy đơn giản nhưng không thực sự hữu dụng - kiểu lỗi chỉ là một giao diện với phương thức Error(), khiến việc xử lý lỗi theo loại trở nên khó khăn, đôi khi phải phân tích chuỗi để xác định loại lỗi.

Điểm chính:

Goroutines và channels là một trong những mô hình đồng thời tốt nhất hiện có
Hệ thống kiểu đơn giản, giao diện không cần triển khai rõ ràng
Thiếu kiểu liệt kê thực sự với kiểm tra đầy đủ
Hằng số chỉ là thời gian biên dịch, không có bất biến thực sự cho giá trị thời gian chạy
Xử lý lỗi thiếu thông tin kiểu, thường phải phân tích chuỗi lỗi

Những Thách Thức Của Soft Delete

Bài viết này phân tích các vấn đề của mẫu xóa mềm phổ biến (thêm cột archived_at hoặc deleted vào bảng) và đề xuất các giải pháp thay thế. Tác giả chỉ ra rằng xóa mềm tuy đơn giản ban đầu nhưng tạo ra nhiều phức tạp: dữ liệu chết tích lũy trong cơ sở dữ liệu, truy vấn phải luôn lọc bỏ các bản ghi đã lưu trữ, việc di chuyển dữ liệu trở nên phức tạp, và việc khôi phục không đơn giản như chỉ đặt archived_at = null.

Tác giả đề xuất ba giải pháp thay thế cho PostgreSQL. Cách đầu tiên là lưu trữ ở cấp ứng dụng - phát ra sự kiện khi xóa và lưu trữ ở dịch vụ khác. Cách thứ hai là sử dụng trình kích hoạt để sao chép các hàng vào bảng lưu trữ trước khi xóa. Cách thứ ba là Thu thập dữ liệu thay đổi dựa trên nhật ghi trước với Debezium hoặc các công cụ tương tự. Mỗi cách đều có sự đánh đổi riêng về độ phức tạp vận hành, độ tin cậy, và chi phí hạ tầng.

Nếu bắt đầu dự án mới hôm nay, tác giả sẽ chọn cách tiếp cận dựa trên trình kích hoạt vì đơn giản thiết lập, giữ bảng chính sạch sẽ, và không cần thêm hạ tầng phức tạp. Bảng lưu trữ dễ truy vấn khi cần và dễ bỏ qua khi không dùng.

Điểm chính:

Xóa mềm với archived_at tạo ra nhiều phức tạp: truy vấn phức tạp, dữ liệu chết tích lũy, di chuyển dữ liệu khó khăn
Lưu trữ ở cấp ứng dụng: đơn giản cho cơ sở dữ liệu nhưng dễ mất dữ liệu nếu có lỗi, hạ tầng phức tạp
Cách tiếp cận dựa trên trình kích hoạt: đơn giản, giữ bảng sạch, lưu trữ dễ truy vấn và dọn dẹp
Thu thập dữ liệu thay đổi (Debezium): không thay đổi mã ứng dụng nhưng hạ tầng phức tạp
Bản sao không xử lý DELETE: ý tưởng mới, chưa kiểm tra, có thể hoạt động cho lưu trữ

Được Trả Lương Tối Thiểu Để Giải Một Bài Toán Bất Khả Thi

Bài viết này kể về câu chuyện có thật của tác giả - một sinh viên khoa học máy tính được trả lương tối thiểu để lau cửa hàng Albert Heijn. Thay vì làm công việc một cách bình thường, tác giả đã biến nó thành một bài toán tối ưu hóa: chuyển bản đồ cửa hàng thành đồ thị, xây dựng trình soạn thảo trực quan bằng Processing, và viết bộ tối ưu hóa lộ trình bằng C++ sử dụng thuật toán luyện giả kim.

Tuy nhiên, giải pháp đầu tiên của thuật toán là một thảm họa - một con đường ngắn nhất về mặt kỹ thuật nhưng hoàn toàn vô dụng trong thực tế với hàng десят rẽ sắc góc. Tác giả nhận ra mình đang tối ưu hóa sai thứ: khoảng cách không phải là tất cả, số lần rẽ quay quan trọng hơn, đà chuyển động quan trọng hơn. Sau khi thêm “hình phạt rẽ” vào hàm chi phí, thuật toán tạo ra những con đường mượt mà hơn dù dài hơn một chút.

Bài viết mở rộng bài học này sang nhiều khía cạnh khác của cuộc sống. Các thuật toán mạng xã hội tối ưu hóa cho mức độ tương tác chứ không phải hạnh phúc. Các thuật toán gợi ý tối ưu hóa cho thời gian xem khiến người dùng xem các lý thuyết âm mưu 6 tiếng liên tục. Các mô hình ngôn ngữ lớn tối ưu hóa cho việc nghe có tự tin chứ không phải đúng sự thật. Các doanh nghiệp tối ưu hóa cho lợi nhuận mà bỏ qua môi trường và đạo đức. Sự chính xác về mặt kỹ thuật là vô giá trị nếu bạn đang giải sai vấn đề.

Điểm chính:

Thuật toán luyện giả kim có thể giải bài toán người bán du lịch cho việc lau nhà siêu thị
Tối ưu hóa sai chỉ số (khoảng cách) tạo ra giải pháp kỹ thuật hoàn hảo nhưng thực tế vô dụng
Lộ trình A ngắn nhất nhưng không thể đi được; lộ trình B dài hơn nhưng thực tế
Mạng xã hội, hệ thống gợi ý, LLM đều tối ưu hóa cho sai mục tiêu
Sự chính xác kỹ thuật vô nghĩa nếu đang giải sai vấn đề từ đầu

Hoàn Thành Lệnh Trong IntelliJ IDEA Ít Phím Tắt Hơn

Bài viết giới thiệu tính năng hoàn thành lệnh mới trong IntelliJ IDEA - một phần mở rộng của tính năng hoàn thành mã thông thường cho phép người dùng khám phá và thực thi các hành động của môi trường phát triển tích hợp ngay từ trình soạn thảo mà không cần nhớ các phím tắt. Thay vì phải nhớ hàng tá phím tắt, bạn chỉ cần gõ . để xem các lệnh trong danh sách hoàn thành thông thường hoặc .. để chỉ xem các lệnh.

Tính năng này giúp sửa lỗi và cảnh báo trong mã, thực hiện các hành động ở cấp tệp hoặc cấp lớp như định dạng lại mã hoặc tối ưu hóa nhập khẩu, hỗ trợ tái cấu trúc và biến đổi mã như tạo lớp, phương thức, trường, hoặc chuyển đổi lớp thành bản ghi. Bạn cũng có thể dùng nó để điều hướng, đổi tên lớp, và thậm chí thêm JavaDoc. Một số lệnh còn có bí danh giúp bạn không cần nhớ tên chính xác.

Hoàn thành lệnh bổ sung cho các tính năng hiện có như hoàn thành hậu tố và mẫu trực tiếp, giữ cho bạn trong trạng thái lập trình mượt mà. Bạn có thể tập trung vào những gì mình muốn làm thay vì làm thế nào để làm. Tính năng này giúp khám phá các tính năng mạnh mẽ mà bạn có thể chưa từng biết đến.

Điểm chính:

Gõ .. để xem tất cả các lệnh có sẵn trong ngữ cảnh hiện tại
Sửa lỗi, cảnh báo, thực hiện hành động cấp tệp mà không cần nhớ phím tắt
Hỗ trợ tái cấu trúc, tạo mã, biến đổi mã sang Java hiện đại
Có thể dùng trong tệp chỉ đọc sau khi bật trong cài đặt
Bí danh cho các lệnh giúp không cần nhớ tên chính xác

Bonus

Images:

Videos: Tác Nhân Trí Tuệ Nhân Tạo Là Gì & Chúng Hoạt Động Như Thế Nào?

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #78

Sun, 01 Feb 2026 00:00:00 +0700

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

Hai Năm Tới Của Kỹ Thuật Phần Mềm

Ngành công nghệ đang đứng trước một điểm ngoặt quan trọng. AI coding đã phát triển từ autocomplete đơn thuần thành các agent có thể tự thực hiện nhiệm vụ phát triển. Sự bùng nổ kinh tế từng thúc đẩy làn sóng tuyển dụng đã nhường chỗ cho yêu cầu hiệu quả: công ty giờ ưu tiên lợi nhuận hơn tăng trưởng, nhân viên giàu kinh nghiệm hơn người mới tốt nghiệp, và team nhỏ hơn nhưng được trang bị công cụ tốt hơn.

Bài viết khám phá năm câu hỏi then chốt sẽ định hình kỹ thuật phần mềm đến năm 2026, với hai kịch bản đối lập cho mỗi câu hỏi. Đây không phải dự báo, mà là những lăng kính để chuẩn bị: (1) Vấn đề junior developer - tuyển dụng có thể sụt giảm khi AI tự động hóa nhiệm vụ cấp nhập môn, hoặc hồi phục khi phần mềm lan rộng mọi ngành; (2) Vấn đề kỹ năng - kỹ năng lập trình cốt lõi có thể teo đi khi AI viết phần lớn code, hoặc trở nên quan trọng hơn khi developer tập trung vào giám sát; (3) Vấn đề vai trò - vai trò developer có thể thu hẹp thành kiểm toán code AI, hoặc mở rộng thành kiến trúc sư điều phối hệ thống; (4) Chuyên gia hay đa năng - chuyên gia hẹp có nguy cơ bị thay thế, T-shaped engineer (biết rộng một chút, sâu một vài lĩnh vực) sẽ được ưu tiên; (5) Vấn đề giáo dục - bằng CS có còn là tiêu chuẩn vàng hay bị các lộ trình học nhanh hơn (bootcamp, online platform, training nội bộ) vượt mặt.

Điểm chính:

84% developer dùng AI support thường xuyên, chuyển từ “viết code từ đầu” sang “soạn prompt và ghép các mảnh AI-generated”
Harvard study: khi công ty adopt generative AI, tuyển dụng junior giảm 9-10% trong 6 quý, trong khi senior hầu như không thay đổi
Big tech tuyển dụng 50% ít hơn fresh graduates trong ba năm qua
Kỹ năng quan trọng: không phải đánh máy boilerplate mà review code AI để tìm lỗi logic, lỗ hổng bảo mật, mismatch với yêu cầu
T-shaped developer: chuyên sâu một hai lĩnh vực (vertical stroke), hiểu rộng nhiều domain khác (horizontal stroke)
45% company planned eliminate bachelor’s degree requirements cho một số vị trí kỹ thuật vào năm 2024
“Lập trình viên giỏi nhất sẽ không phải là người code nhanh nhất, mà người biết khi nào không tin AI”
Điều kiện sống sót: cập nhật kỹ năng liên tục, đa năng hóa, tập trung vào yếu tố con người (sáng tạo, tư duy phản biện, cộng tác)

Cơ Sở Dữ Liệu Năm 2025: Một Năm Đánh Giá

Bài viết tổng hợp chi tiết các xu hướng và sự kiện quan trọng trong thế giới cơ sở dữ liệu năm 2025. PostgreSQL tiếp tục thống trị với phiên bản 18 ra mắt tháng 11, bổ sung hệ thống nhập xuất bất đồng bộ và hỗ trợ skip scans. Tuy nhiên, tin nóng nhất là làn sóng mua bán các công ty PostgreSQL: Databricks thâu tóm Neon với 1 tỷ USD, Snowflake mua CrunchyData với 250 triệu USD, và Microsoft ra mắt HorizonDB. Cuộc đua PostgreSQL phân tán cũng nóng lên với ba dự án cạnh tranh: Multigres (do Supabase phát triển), Neki (PlanetScale), và PgDog.

Một xu hướng lớn khác là MCP (Model Context Protocol) - chuẩn giao tiếp giữa mô hình ngôn ngữ và cơ sở dữ liệu. Sau khi OpenAI hỗ trợ MCP vào tháng 3, mọi nhà cung cấp cơ sở dữ liệu đều tung ra MCP server riêng. Tuy nhiên, tác giả cảnh báo về rủi ro bảo mật khi cấp quyền truy cập không giới hạn cho các tác nhân trí tuệ nhân tạo. Thế giới định dạng tệp cũng sôi động với năm định dạng mới ra mắt nhằm cạnh tranh Parquet: FastLanes, F3, Vortex, AnyBlox, và Amudai.

Năm 2025 chứng kiến nhiều thương vụ mua bán: IBM mua DataStax (3 tỷ USD), Salesforce mua Informatica (8 tỷ USD), và IBM mua Confluent. Hai thương vụ sáp nhập đáng chú ý là Fivetran hợp nhất với dbt Labs để tạo nên “gã khổng lồ ETL”. Về tài chính, Databricks gây quỹ thành công với hai vòng gọi vốn 4 tỷ và 1 tỷ USD, trong khi nhiều startup cơ sở dữ liệu phải đóng cửa. Năm nay cũng ghi nhận Larry Ellison trở thành người giàu nhất thế giới với tài sản 393 tỷ USD, vượt qua kỷ lục lịch sử của John D. Rockefeller.

Điểm chính:

PostgreSQL thống trị với phiên bản 18, bổ sung hệ thống nhập xuất bất đồng bộ và skip scans
Làn sóng mua bán: Databricks mua Neon (1 tỷ USD), Snowflake mua CrunchyData (250 triệu USD), Microsoft ra mắt HorizonDB
Cuộc đua PostgreSQL phân tán: ba dự án cạnh tranh (Multigres, Neki, PgDog)
MCP trở thành chuẩn giao tiếp giữa mô hình ngôn ngữ và cơ sở dữ liệu, mọi nhà cung cấp đều tung ra MCP server
Cảnh báo bảo mật: cần cấp quyền tối thiểu cho tác nhân AI để tránh rủi ro khi chúng “hoành hành”
Định dạng tệp: năm định dạng mới cạnh tranh Parquet (FastLanes, F3, Vortex, AnyBlox, Amudai)
Thương vụ mua bán: IBM-DataStax (3 tỷ USD), Salesforce-Informatica (8 tỷ USD), IBM-Confluent
Sáp nhập: Fivetran + dbt Labs tạo nên “gã khổng lồ ETL”
Nhiều startup đóng cửa: Fauna, PostgresML, Hydra, MyScaleDB, Voltron Data
Larry Ellison trở thành người giàu nhất lịch sử (393 tỷ USD), vượt kỷ lục của John D. Rockefeller (340 tỷ USD)

12 Dự Báo Cho Năm 2026

Tác giả đưa ra 12 dự báo cho năm 2026, tập trung vào sự trỗi dậy của các hệ thống tác nhân AI sẽ thay đổi kiến trúc cơ sở dữ liệu và chuyển đổi web sang thiết kế ưu tiên tác nhân. Dự báo nổi bật nhất: doanh nghiệp chi trả nhiều cho AI agents hơn cho con người lần đầu tiên, với Waymo rides đã đắt hơn Uber 31% nhưng nhu cầu vẫn tăng do ưu tiên an toàn và độ tin cậy. Năm 2026 dự kiến trở thành năm kỷ lục về thanh khoản với các đợt IPO lớn từ SpaceX, OpenAI, Anthropic, Stripe và Databricks, trong đó SpaceX và OpenAI sẽ nằm trong 10 đợt IPO lớn nhất lịch sử.

Vector databases sẽ hồi sinh và trở thành hạ tầng thiết yếu trong stack AI khi các mô hình đa phương thức và mô hình không gian trạng thái đòi hỏi kiến trúc dữ liệu mới. Theo METR, thời gian thực hiện nhiệm vụ của AI tăng gấp đôi mỗi 7 tháng, và đến cuối 2026, các tác nhân AI sẽ tự chủ thực hiện luồng công việc 8+ giờ, thay đổi căn bản cách công ty phân bổ nhân sự. Ngân sách AI sẽ bị giám sát kỹ lưỡng lần đầu tiên, thúc đẩy sự phổ biến của các ngôn ngữ models nhỏ và mã nguồn mở với chi phí thấp hơn 10 lần.

Google sẽ tạo khoảng cách với đối thủ thông qua sự đa dạng trong AI: frontier models, suy luận trên thiết bị, tạo video, mã nguồn mở và tích hợp tìm kiếm. Stablecoin sẽ chiếm 30% thanh toán quốc tế vào tháng 12, thay thế các đường ray SWIFT truyền thống. Các mô hình truy cập dữ liệu của tác nhân sẽ gây áp lực và làm vỡ cơ sở dữ liệu hiện tại với số lượng truy vấn tăng ít nhất một cấp độ. Xây dựng trung tâm dữ liệu sẽ đạt 3,5% GDP Mỹ, quy mô tương tự mở rộng đường sắt lịch sử. Web sẽ chuyển sang thiết kế ưu tiên tác nhân vì nhiều quyết định mua hàng hiện được thực hiện thông qua nghiên cứu của tác nhân. Cloudflare sẽ trở thành cổng cho thanh toán của tác nhân thông qua giao thức x402.

Điểm chính:

Doanh nghiệp chi trả nhiều cho AI agents hơn con người lần đầu, Waymo rides đắt hơn Uber 31% nhưng nhu cầu vẫn tăng
2026: năm kỷ lục về thanh khoản với IPO từ SpaceX, OpenAI, Anthropic, Stripe, Databricks
Vector databases hồi sinh và trở thành hạ tầng thiết yếu trong stack AI
AI agents tự chủ thực hiện luồng công việc 8+ giờ vào cuối 2026 (theo METR: thời gian tăng gấp đôi mỗi 7 tháng)
Ngân sách AI bị giám sát, ngôn ngữ models nhỏ và mã nguồn mở phổ biến với chi phí thấp hơn 10 lần
Google tạo khoảng cách thông qua sự đa dạng AI: frontier models, on-device inference, video generation, open-source, search integration
Agent observability trở thành lớp cạnh tranh nhất trong inference stack
Stablecoin chiếm 30% thanh toán quốc tế, thay thế SWIFT cho B2B
Tác nhân gây áp lực cực lớn cho cơ sở dữ liệu với truy vấn tăng ít nhất một cấp độ
Trung tâm dữ liệu đạt 3,5% GDP Mỹ, quy mô tương tự mở rộng đường sắt
Web chuyển sang thiết kế ưu tiên tác nhân cho tài liệu và website
Cloudflare trở thành cổng thanh toán cho tác nhân thông qua giao thức x402

Sổ Tay Garbage Collection

Đây là ấn bản thứ hai của cuốn sách kinh điển về quản lý bộ nhớ tự động. Cuốn sách đầu tiên “Garbage Collection” của Richard Jones (Wiley, 1996) là một cột mốc quan trọng trong lĩnh vực quản lý bộ nhớ tự động. Phiên bản kế tiếp “The Garbage Collection Handbook: The Art of Automatic Memory Management” đã ghi nhận trạng thái của lĩnh vực này vào năm 2012. Tuy nhiên, sự phát triển công nghệ đã làm cho quản lý bộ nhớ trở nên thách thức, thú vị và quan trọng hơn bao giờ hết. Ấn bản thứ hai này cập nhật handbook, tổng hợp kiến thức từ các nhà nghiên cứu và phát triển quản lý bộ nhớ tự động trong sáu mươi năm qua.

Cuốn sách đề cập đến các thách thức mới cho garbage collection do những tiến bộ gần đây trong phần cứng và phần mềm, cũng như môi trường thực thi chương trình. Nó khám phá hậu quả của những thay đổi này đối với người thiết kế và thực thi các bộ thu gom rác hiệu suất cao. Cùng với các thuật toán đơn giản và truyền thống, cuốn sách bao gồm các kỹ thuật tiên tiến nhất: song song, tăng dần, đồng thời và thu gom rác thời gian thực. Các thuật toán và khái niệm thường được mô tả bằng mã giả và hình ảnh minh họa.

Sự chấp nhận gần như phổ biến garbage collection bởi các ngôn ngữ lập trình hiện đại làm cho việc hiểu kỹ lưỡng chủ đề này trở nên thiết yếu đối với bất kỳ lập trình viên nào. Handbook uy tín này đưa ra cái nhìn chuyên sâu về cách thức hoạt động của các bộ thu gom khác nhau cũng như các vấn đề hiện đang đối mặt với garbage collectors. Với kiến thức này, lập trình viên có thể tự tin chọn và cấu hình trong nhiều lựa chọn garbage collectors.

Điểm chính:

Ấn bản thứ hai cập nhật cuốn sách kinh điển về quản lý bộ nhớ tự động (1996, 2012)
Tổng hợp kiến thức từ 60 năm nghiên cứu và phát triển garbage collection
Bao gồm thuật toán song song, tăng dần, đồng thời và thời gian thực
Phân tích chi tiết các bộ thu gom thương mại hiệu suất cao hiện đại
Giải thích các khía cạnh khó của garbage collection, bao gồm giao diện với hệ thống runtime
Thêm hơn 90 trang, bao gồm các chương mới về lưu trữ và garbage collection nhận thức năng lượng
E-book với hơn 37.000 liên kết đến các chương, mục, thuật toán, hình ảnh, nghiên cứu gốc
Cơ sở dữ liệu trực tuyến với gần 3.400 ấn phẩm liên quan đến garbage collection
Đã có bản dịch tiếng Trung và tiếng Nhật xuất bản năm 2016

Vibe-Coded Là “Made in China” Mới

Bài viết phân tích khái niệm “vibe coding” được Andrej Karpathy đưa ra vào đầu năm 2025: một cách lập trình nơi bạn “hoàn toàn đầu hàng cho vibes, chấp nhận số mũ, và quên rằng code tồn tại” - để LLM xử lý triển khai trong khi bạn tập trung vào những gì muốn xây dựng, không phải cách xây dựng. Tác giả so sánh sự kỳ thị đối với “vibe-coded” hiện nay với nhãn “Made in China” trong quá khứ - từng là viết tắt của hàng giá rẻ, vứt đi, dù thực tế đã thay đổi.

Trước khi lập trình hỗ trợ bởi AI tồn tại, các nhà phát triển mã nguồn mở phải đầu tư lượng thời gian khổng lồ chỉ để đạt được điểm xuất bản. Khó khăn của việc xây dựng phần mềm là một bộ lọc - bạn phải thực sự đứng đằng sau một ý tưởng để đưa nó đến mức đó. Bây giờ rào cản đã biến mất. Mọi người có thể tạo dựng một ứng dụng trong vài giờ mà trước đây mất vài tháng. Quan trọng hơn, mọi người có thể lập trình ở trên trình độ của họ. Bạn không cần hiểu sâu lĩnh vực. Bạn không cần biết tại sao kiến trúc của mình hoạt động. Bạn chỉ cần tầm nhìn và đủ kỹ năng prompting để tạo ra thứ gì đó hoạt động.

Điều này tạo ra kịch bản nơi tác giả dự án có thể không hiểu code họ phát hành. Họ không thể sửa các trường hợp đặc biệt vì không biết hệ thống thực sự hoạt động thế nào. Họ không thể mở rộng tính năng vì không thiết kế nền tảng. Họ không thể bảo trì dự án dài hạn vì không có “sự gắn kết cảm xúc” với thứ mất một buổi chiều để xây dựng. Cộng đồng cảm nhận điều này. Sự thiếu tin tưởng không chỉ về chất lượng code, mà còn về tuổi thọ dự kiến.

Tuy nhiên, một số nhà phát triển tận tâm nhất đã tìm cách sử dụng AI mà không kích hoạt báo động. DHH (tạo ra Ruby on Rails): “Bạn không thể để sự lộn xộn và ngại ngùng phủ nhận sự kỳ diệu của AI.” Tanner Linsley (tạo TanStack): “Ở tỷ lệ nhỏ và có trách nhiệm, có.” Boris Cherny (tạo Claude Code): “Trong ba mươi ngày qua, 100% đóng góp của tôi cho Claude Code được viết bởi Claude Code.” Mô hình: các nhà phát triển quan tâm sâu sắc về chất lượng không từ chối AI. Họ tích hợp nó một cách cẩn thận, vẫn là tác giả trong khi để AI xử lý công việc nặng nhọc.

Điểm chính:

“Vibe coding” = để LLM xử lý triển khai, tập trung vào những gì muốn xây dựng không phải cách xây dựng
Trước AI: khó khăn xây dựng phần mềm là bộ lọc, phải đầu tư thời gian/khổ luyện để xuất bản
Hiện tại: rào cản biến mất, mọi người có thể code ở trên trình độ của họ
Vấn đề: tác giả có thể không hiểu code họ phát hành, không thể sửa/mở rộng/bảo trì
“Vibe-coded” trở thành nhãn giống “Made in China” cũ = viết tắt của hàng giá rẻ, vứt đi
AI output có tính aesthetic nhận biết: giọng văn phong, UI gradient tím, tài liệu sound helpful nhưng hollow
Sự hoài nghi không vô lý: hệ sinh thái đang cố gắng bảo vệ mình trong khi quy tắc được viết lại
Các nhà phát triển tận tâm vẫn dùng AI có trách nhiệm: DHH, Tanner Linsley, Boris Cherny
Thời gian vẫn là bộ lọc: dự án bảo trì 2 năm với người dùng thực sự chứng cam kết không thể giả mạo
Chúng ta trong giai đoạn chuyển tiếp khó xử, cần tìm bằng chứng mới về cam kết thay vì độ khó tạo ra

Lỗi Production Khiến Tôi Quan Tâm Đến Undefined Behavior

Tác giả chia sẻ câu chuyện về một lỗi production trong hệ thống C++ xử lý hàng tỷ euro thanh toán mỗi năm. Lỗi bug report cho thấy endpoint HTTP trả về response không thể: cả hai trường error và succeeded đều là true, dù code logic rõ ràng chỉ set một trong hai. Sau khi điều tra, tác giả phát hiện vấn đề liên quan đến undefined behavior trong C++.

Vấn đề nằm ở việc khởi tạo struct. Trong C, Response response; rõ ràng là undefined behavior vì struct không được khởi tạo. Nhưng trong C++, quy tắc phức tạp hơn: nếu struct là non-POD (Plain Old Data) có thành viên non-POD như std::string, default constructor được gọi. Tuy nhiên, default constructor được compiler tự động tạo ra chỉ khởi tạo các thành viên non-POD, còn các thành viên primitive (bool, int, v.v.) thì không. Kết quả: std::string data được khởi tạo đúng, nhưng error và succeeded chứa giá trị rác.

Giải pháp đơn giản: dùng Response response{}; để force zero initialization tất cả các trường. Hoặc implement default constructor rõ ràng, hoặc định nghĩa default values cho các trường trong struct definition. Bài viết cũng đề cập đến các công cụ phát hiện: clang-tidy, Address Sanitizer (ASan), và tự viết libclang plugin để quét codebase. Tác giả kết luận rằng C++ có quá nhiều cách khởi tạo biến và hầu hết đều sai, trong khi nhiều ngôn ngữ khác (C, Go, Rust) tiếp cận đơn giản hơn: struct là plain data, hoặc compiler force set mỗi trường, hoặc zero-initialize tất cả.

Điểm chính:

Lỗi production trong C++ system xử lý hàng tỷ euro thanh toán mỗi năm
Bug report: cả error và succeeded đều true, dù logic code chỉ set một trong hai
Nguyên nhân: Response response; - struct non-POD với std::string thành viên
C++ rule phức tạp: default constructor tự động chỉ init non-POD members, primitives thì không
Giải pháp: Response response{}; force zero initialization, hoặc implement default constructor, hoặc default field values
C++ có quá nhiều cách khởi tạo biến và hầu hết đều sai
Tools phát hiện: clang-tidy, Address Sanitizer (ASan), Valgrind, libclang plugin
ASan báo: “load of value 8, which is not a valid value for type ‘bool’”
Một số types không trigger undefined behavior: std::byte, unsigned char, unsigned char
Tác giả thích approach của C/Go/Rust: struct là plain data, force set hoặc zero-init
Undefined behavior nguy hiểm vì code không còn là source of truth, impossible values xuất hiện

Đừng Sa Vào Anti-AI Hype

Tác giả (người tạo Redis) chia sẻ quan điểm về AI và lập trình. Mặc dù yêu thích viết code từng dòng và theo đuổi phần mềm tối giản với “chất lượng con người”, ông thừa nhận AI sẽ thay đổi lập trình mãi mãi. Năm 2020 ông nghỉ việc để viết tiểu thuyết về AI và universal basic income. Cuối 2024 ông mở kênh YouTube về AI. Ông từng nghĩ chúng ta có nhiều năm trước khi lập trình được định hình lại hoàn toàn, nhưng không còn tin vậy nữa.

Gần đây, LLMs hiện tại có thể hoàn thành các subtasks lớn hoặc dự án quy mô trung bình một mình, hầu như không cần hỗ trợ, chỉ cần gợi ý tốt về kết quả cuối cùng. Độ thành công phụ thuộc vào loại lập trình (càng cô lập và càng dễ diễn đạt bằng văn bản thì càng tốt: system programming đặc biệt phù hợp) và khả năng tạo representation tinh thần của vấn đề để giao tiếp với LLM. Nhưng nói chung, hiện rõ ràng rằng với hầu hết dự án, tự viết code không còn hợp lý, trừ khi để giải trí.

Trong một tuần, chỉ prompting và kiểm tra code để hướng dẫn thỉnh thoảng, trong vài giờ ông hoàn thành bốn tác phẩm: (1) Sửa đổi linenoise library để hỗ trợ UTF-8 và tạo framework cho line editing testing với emulated terminal; (2) Sửa transient failures trong Redis test - vấn đề timing, TCP deadlock; Claude Code iterated, inspected process state và fixed bugs; (3) Pure C library để inference BERT embedding models - Claude Code tạo trong 5 phút, 700 dòng code, cùng output và tốc độ với PyTorch (chậm 15%); (4) Thay đổi Redis Streams internals - Claude Code reproduced work trong 20 phút hoặc ít hơn từ design document.

Tác giả cảm thấy vinh dự khi code của ông được LLMs ingest, coi đó là sự tiếp nối những gì ông cố gắng cả đời: democratizing code, systems, knowledge. LLMs sẽ giúp chúng ta viết phần mềm tốt hơn, nhanh hơn, và cho phép small teams cạnh tranh với bigger companies - giống như open source software đã làm trong thập niên 90. Tuy nhiên, ông lo ngại về sự tập trung hóa - công nghệ này quá quan trọng để nằm trong tay vài công ty. Ông tin neural networks, ở quy mô, đơn giản là có thể làm những điều incredible, và không có đủ “magic” trong AI frontier hiện tại để các labs khác không bắt kịp.

Điểm chính:

Tác giả Redis: yêu thích viết code từng dòng, nhưng thừa nhận AI thay đổi lập trình mãi mãi
LLMs hiện tại có thể hoàn thành subtasks lớn/dự án trung bình một mình, hầu như không cần hỗ trợ
Trong một tuần: 4 tác phẩm hoàn thành trong vài giờ thay vì tuần nhờ AI
(1) UTF-8 support cho linenoise library với testing framework
(2) Sửa transient failures trong Redis test (timing, TCP deadlock)
(3) Pure C library cho BERT embedding inference - 5 phút, 700 dòng, speed = PyTorch
(4) Redis Streams internals changes - reproduced trong 20 phút từ design doc
Tự viết code không còn hợp lý cho hầu hết dự án, trừ giải trí
Vinh dự code được ingest: democratizing code/systems/knowledge như open source trong 90s
LLMs giúp viết phần mềm tốt hơn, nhanh hơn, small teams cạnh tranh big companies
Lo ngại tập trung hóa: công nghệ quá quan trọng để nằm trong tay vài công ty
Neural networks không có đủ “magic” để các labs khác không bắt kịp
Khuyên: đừng từ chối AI, test tools mới với tuần công việc, không phải test 5 phút
Động lực lập trình: building - giờ có thể build nhiều hơn và tốt hơn với AI

Performance Hints Của Abseil

Abseil là tập hợp thư viện C++ do Google phát triển, đi kèm với hướng dẫn tối ưu hóa hiệu năng dựa trên kinh nghiệm thực tế của họ. Performance Hints cung cấp các kỹ thuật tối ưu hóa thực tế thay vì micro-optimizations lý thuyết. Dự án bao gồm “Performance Tips of the Week” - được mô tả như một loại “Effective analysis” cho tối ưu hóa hiệu năng.

Các tips quan trọng bao gồm: Tip #70 về việc định nghĩa và đo lường thành công tối ưu hóa, Tip #72 về tối ưu hóa chính quá trình tối ưu hóa, Tip #74 về việc tránh “sweeping streetlights” - các cạm bẫy tối ưu hóa. Tip #90 thảo luận về cách đưa ra và sử dụng ước lượng trong vòng đời tối ưu hóa. Tip #64 nhấn mạnh tầm quan trọng của API tốt và trừu tượng hóa đúng để tìm kiếm cơ hội tối ưu hóa.

Abseil tập trung vào các chiến lược tối ưu hóa thực tế cho code C++ hiện đại, bao gồm: hiểu rõ chi phí thực sự của các operations, sử dụng profiler để tìm bottleneck, tránh premature optimization, thiết kế API tốt cho phép tối ưu hóa mà không breaking interface, và hiểu cách compiler optimizations hoạt động. Các tips dựa trên kinh nghiệm thực tế từ việc tối ưu hóa các hệ thống lớn quy mô của Google.

Điểm chính:

Abseil: thư viện C++ từ Google với hướng dẫn tối ưu hóa hiệu năng thực tế
“Performance Tips of the Week” - các tips tối ưu hóa dựa trên kinh nghiệm thực tế
Tip #70: định nghĩa và đo lường thành công tối ưu hóa
Tip #72: tối ưu hóa chính quá trình tối ưu hóa
Tip #74: tránh “sweeping streetlights” - cạm bẫy tối ưu hóa
Tip #90: ước lượng trong vòng đời tối ưu hóa
Tip #64: API tốt và trừu tượng hóa đúng để tìm cơ hội tối ưu hóa
Tập trung chiến lược thực tế: profiler tìm bottleneck, tránh premature optimization
Thiết kế API cho phép tối ưu hóa mà không breaking interface
Hiểu cách compiler optimizations hoạt động
Kinh nghiệm từ tối ưu hóa các hệ thống lớn quy mô của Google

Triển Vọng Thị Trường Việc Làm Kỹ Thuật Phần Mềm 2026

Bài viết phân tích triển vọng thị trường việc làm kỹ thuật phần mềm năm 2026. Kỹ thuật phần mềm từng được coi là nghề nghiệp an toàn nhất, giờ là công việc công nghệ dễ bị tổn thương nhất với layoffs gần như mỗi tuần. Companies đổ lỗi cho AI, nhưng thực tế phức tạp hơn. Dữ liệu Indeed qua FRED cho thấy hiring surge khổng lồ peak giữa 2022, rồi giảm mạnh đến 2024, và thị trường không bao hồi.

Nguyên nhân thực sự: hiring boom lịch sử 2021-2022 được thúc đẩy bởi digitization. Từ Big Tech đến Startup, ai cũng overhiring. Khi thế giới chuyển online gần như overnight, companies không còn lựa chọn nào ngoài việc speed up digital efforts. FOMO tạo ra rush. Startup thấy cơ hội hiếm: users online nhiều hơn, investors đổ tiền, muốn làm products nhanh hơn. Engineers được thuê trước khi có clear work. Low interest rates cũng đóng vai trò. Sau đó họ nhận ra demand không tăng cùng pace với hiring, extra people thành gánh nặng.

AI trở thành scapegoat. AI tools rẻ hơn, viết basic code trong vài phút, không đòi salary cả năm. Companies nghĩ: thay 3 engineers bằng 1 engineer với AI tools. Stock market đi lên, cách boost stock price: cut jobs và giải thích có thể làm same work với AI bots rẻ hơn. Nhưng họ vẫn cần engineers, chỉ là có euphoria rồi correction dẫn đến crisis. Giờ back to normal khi tiến đến 2026.

Lý do lớn khác: large companies thoải mái với remote hiring. Tại sao hire engineer USA với salary rất cao khi có thể hire người từ Asia với fraction of cost? Senior engineer USA có thể $100k/năm, Argentina $60k, India $40k. Math đơn giản cho companies watching bottom line. AI thành PR-friendly excuse: “we are replacing jobs with AI” nghe forward-thinking hơn là “we are shipping jobs overseas”.

AI không phải culprit, nhưng không có nghĩa là không quan trọng. METR study tìm thấy experienced software engineers thực tế 19% less productive khi dùng AI tools cho real-world tasks. AI là tool, không phải replacement. Software engineering jobs sẽ không biến mất, nhưng demand cho basic coding jobs sẽ giảm. Magnus Grimeland (Antler VC) cho rằng AI sẽ tăng demand cho software engineers vì AI systems sẽ mắc lỗi, human engineers vẫn cần để fix errors. More code means more errors.

US Bureau of Labor Statistics vẫn expect software developer jobs grow ~15%, chậm hơn prediction trước là 22% nhưng growth vẫn là growth. SignalFire báo Meta, Netflix, Uber, Google hire engineers faster hơn people leaving. Hiring ratios sit well above 100 - dấu mạnh engineering work đang tăng, không giảm. What’s changing là skill bar. Jobs require actual engineering thinking, designing systems, optimizing performance, ensuring security vẫn rất được demand.

Điểm chính:

Software engineering: từ career an toàn nhất thành dễ bị tổn thương nhất với layoffs mỗi tuần
Hiring boom 2021-2022: digitization rush, FOMO, overhiring, low interest rates
Correction 2022-2024: demand không tăng cùng pace, AI thành scapegoat
Remote hiring: hire Asia fraction of cost so với USA, AI thành PR-friendly excuse
METR study: experienced engineers 19% less productive với AI tools cho real-world tasks
AI là tool, không phải replacement - more code means more errors cần fix
US Bureau of Labor: software developer jobs vẫn grow 15% (chậm hơn 22% prediction)
SignalFire: Meta, Netflix, Uber, Google hire faster than people leaving
What’s changing: skill bar - need engineering thinking, system design, performance, security
Top languages 2026: Python (AI/ML), JavaScript/TypeScript (frontend/full-stack), Go (backend/infrastructure), Java (enterprise), Swift (iOS)
New opportunities: AI engineering, AI infrastructure, data engineering, AI safety
AI/ML jobs share tăng từ 10% đến 50% (2023-2025)
Entry-level jobs giảm 40% so với pre-2022, CS graduates và bootcamp grads tăng
Gartner: 80% engineering workforce cần upskill để keep pace với generative AI by 2027
Median salary software engineer US 2026: $130,000
Market maturing: harder to break in nhưng financial case vẫn strong

Bonus

Hình ảnh:

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #74

Sat, 27 Dec 2025 00:00:00 +0700

Lâu rồi chưa pay 1 cái gì liên quan đến AI (từ thời Claude subscription để thử nghiệm Claude Code). Nay mới mua thử gói GLM Coding Plan của Z.ai để trải nghiệm. Gói này hiện cho phép dùng model mới nhất của Z.ai là GLM-4.7. Từ nay mình sẽ tranh thủ dùng Claude Code với Z.ai API để ‘bào’ cho xứng đáng số tiền bỏ ra^^. Mời bạn thưởng thức Newsletter #74.

Goodbye Microservices: From 100s of problem children to 1 superstar

Twilio Segment chia sẻ hành trình từ hơn 100 microservices quay lại monolith. Ban đầu dùng microservices để giải quyết head-of-line blocking - tạo riêng service và queue cho từng đích đến. Nhưng khi scale lên (trung bình 3 đích/tháng), các vấn đề nảy sinh: shared libraries phân kỳ giữa codebase, mỗi service có pattern tải khác nhau khiến scale khó khăn.

Họ gộp 140+ services thành một service, chuyển về monorepo, xây dựng Traffic Recorder để test nhanh hơn. Kết quả: developer velocity tăng, operational overhead giảm. Trade-off: khó cô lập lỗi hơn, caching kém hiệu quả, nhưng với test suite vững chắc thì đáng đổi.

Điểm chính:

Microservices giải quyết blocking nhưng tạo overhead lớn
Shared libraries phân kỳ làm mất lợi ích thống nhất
Monolith tăng velocity, giảm burden
Traffic Recorder test nhanh hơn
Cần test suite vững khi chuyển về monolith

5 engineering dogmas it’s time to retire

5 quan điểm cần xem xét lại: (1) “Đừng reinvent the wheel” - lạm dụng dependencies có rủi ro bảo mật, ví dụ left-pad (11 dòng) từng break build của Facebook/Netflix. (2) “Mọi PR phải review” - review có giá trị nhưng quy trình bắt buộc làm chậm, một số công ty để engineer tự merge và chỉ review khi cần. (3) “Sprints 2-4 tuần” - Shape Up với 6-week cycles + cool-down time là giải pháp thay thế. (4) “Feature flag cho mọi change” - lạm dụng làm codebase phức tạp, tạo cảm giác an toàn giả. (5) “Comment = code phức tạp” - cân bằng, đôi khi comment tiết kiệm nhiều thời gian.

Điểm chính:

Dependencies cần cân nhắc, có rủi ro bảo mật
Review có giá trị nhưng quy trình bắt buộc chậm
Shape Up: 6-week cycles + cool-down
Feature flag lạm dụng phức tạp, an toàn giả
Comment đôi khi tiết kiệm thời gian
Cần cân bằng dogmas với thực tế

What Does a Database for SSDs Look Like?

Database được thiết kế riêng cho SSDs trông như thế nào? Postgres/MySQL thiết kế cho spinning disks, nhưng SSD hiện tốt hơn ~1000x. Cloud networks cũng tốt hơn 1000x. Tác giả tiếp cận qua 5 góc độ:

Five Minute Rule update 2025: cache giữ pages ~30 seconds cho optimal cost
Optimal transfer size cho SSD ~32kB
Durability qua distributed log, không chỉ local disk
Chỉ incur cross-AZ latency tại commit time
Use high-quality clocks cho coordination

Tóm lại, giữ relational model/SQL nhưng move durability/scale/HA thành distributed concerns, toss local durability optimizations.

Điểm chính:

Cache giữ pages ~30 seconds (thay vì 5 phút năm 1986)
Transfer size ~32kB optimal cho SSD
Durability qua distributed log multi-AZ
Cross-AZ latency chỉ tại commit
Relational model giữ, distributed concerns thêm

The Economics of System Design: FinOps, Auto-Scaling, and Spot Instances

Cost optimization trong system design thường bị bỏ qua. Khoảng 30% cloud spend là waste. Inefficiencies nhỏ scale lên thành expenses lớn. 5 strategies:

Cost-conscious architecture: microservices trade-offs, simplicity
Right-sizing + auto-scaling: không over-provision, use serverless
Caching + query optimization: giảm database load
Hunt idle resources: shutdown forgotten instances
Monitoring + FinOps: treat cost như performance metric

Well-designed system không chỉ scalable/performant mà còn cost-efficient.

Điểm chính:

30% cloud spend là waste
Design cost-conscious với simplicity
Right-sizing + auto-scaling + serverless
Caching giảm database load
Shutdown idle resources
Treat cost như performance metric

The Big-O Complexity of Vibe Coders

Vibe coding (dùng LLMs để code) hiện được đánh giá bằng tốc độ, nhưng khi scale thì cost quan trọng hơn. Teams không dùng vibe coding chậm hơn, teams lạm dụng tốn nhiều tokens. Iterations không free - mỗi prompt consumes tokens = cost.

Workflow nhiều fast iterations có thể O(n²) complexity. Vague prompts expand solution space, precise prompts converge faster. Best vibe coders = lowest Big-O tokens per shipped outcome. Token-efficient vibe coding scales teams.

Exploratory/creative work inherently inefficient, không nên optimize all.

Điểm chính:

Vibe coding đánh giá bằng tốc độ, cost quan trọng hơn khi scale
Iterations consumes tokens = cost
Workflow nhiều iterations có thể O(n²)
Precise prompts converge nhanh hơn vague
Best vibe coders = lowest tokens/outcome
Exploratory work inherently inefficient

Design is more than code

Design không chỉ về code. Recent discourse tập trung designers có nên code không, nhưng điều này reductive. Câu hỏi lớn hơn: designers sẽ contributing như thế nào với AI và new tools?

Design process có 2 stages: designing the problem và designing the solution. Designing the problem: question the problem, không assume - most failures do unclear problem. Designing the solution: conceptual stage (tìm form) và execution stage (build nó). Code/material essential cho execution, nhưng không cho tất cả.

Tác giả worry về decline trong consideration, không phải tools. Design về finding right problem/intent/vision.

Điểm chính:

Debate designers coding reductive
Design comes in many flavors
Process: design problem → design solution
Question problem, không assume
Conceptual → execution stages
Code essential cho execution, không all
Worry decline consideration, không tools

How we saved 70% CPU and 60% memory in Refinery

Honeycomb optimize Refinery telemetry pipeline: giảm 70% CPU và 60% memory. Root cause là dynamic attributes calculation - parse attributes nhiều lần, create intermediate allocations inefficiencies.

Refactor: (1) Parse attributes chỉ một lần early, (2) Reuse parsed data, (3) Eliminate intermediate allocations, (4) Use efficient data structures.

Profiling trước khi optimize critical - find bottlenecks first. Trade-off: code phức tạp hơn, harder maintain, nhưng performance gains justify trong case này.

Điểm chính:

High resource usage do attributes calculation
Parse multiple times, intermediate allocations inefficient
Refactor: parse once, reuse, eliminate allocations
Result: 70% CPU, 60% memory reduction
Profiling trước khi optimize
Trade-off: phức tạp hơn nhưng worth it

From Junior to Senior: 7 API Design Patterns That Scale

7 architectural decisions cho scalable APIs - khác biệt junior/senior. Junior focus logic, senior focus system communication. API là critical component của distributed systems.

Resource-Oriented Design (RESTful) thay vì Action-Based (RPC): think resources (nouns), không actions (verbs). Predictability là valuable trait.
Proper HTTP Status Codes: 2xx/4xx/5xx categories matter cho debugging
Pagination: Offset (beginner) vs Cursor (scalable, O(1))
Idempotency Keys prevent duplicate charges
Rate Limiting protects từ overload
API Versioning prevents breaking clients
Documentation critical với OpenAPI/Swagger

Good API design = stable foundation, poor design = bottleneck.

Điểm chính:

Junior focus logic, senior focus communication
RESTful (resources) thay vì RPC (actions)
HTTP status codes categories matter
Cursor pagination scalable hơn offset
Idempotency keys prevent duplicates
Rate limiting protects overload
Versioning prevents breaking clients
Documentation critical

Bonus

Images

Đánh giá: Z.ai xử lý 1 url tương đối nhanh, ban đầu mình cũng thấy khá ok, tuy nhiên thêm càng nhiều thì có vẻ càng bị dài & lạm dụng tiếng Anh. Mình đã phải yêu cầu tóm gọn lại một xíu. Hi vọng sẽ cải thiện được sau (vì lỡ mua rùi và non-refundable hiuhiu)

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #73

Sat, 20 Dec 2025 00:00:00 +0700

Gầy đây mình mới biết OpenRouter đã hỗ trợ tích hợp Claude Code, nên nay dùng thử. Bài viết này được thực hiện bởi Claude Code + Open Router + Z.AI: GLM 4.5 Air (free). Mời bạn thưởng thức Newsletter #73.

System Design Deep Dive: Time Series Databases (TSDBs) Explained

Cơ sở dữ liệu chuỗi thời gian (TSDB) là giải pháp tối ưu cho dữ liệu có thứ tự thời gian, cung cấp khả năng nhập dữ liệu hiệu suất cao và truy vấn nhanh chóng dựa trên thời gian. Khác với cơ sở dữ liệu truyền thống, TSDB tập trung vào dữ liệu có dấu thời gian và xử lý chúng xuất sắc.

TSDB có đặc điểm nổi bật: nén dữ liệu hiệu quả bằng các kỹ thuật như mã hóa delta và mã hóa độ dài chạy; tự động quản lý vòng đời dữ liệu với chính sách lưu trữ và giảm mẫu; truy phạm vi thời gian nhanh chóng nhờ tính năng chỉ mục thời gian.

Ứng dụng phổ biến: giám sát hạ tầng theo dõi chỉ số máy chủ và ứng dụng; xử lý dữ liệu cảm biến IoT từ các thiết bị liên tục.

So với cơ sở dữ liệu quan hệ, TSDB vượt trội ở việc ghi tần suất cao và truy vấn phạm vi thời gian nhanh trên dữ liệu tuần tự, trong khi cơ sở dữ liệu quan hệ phù hợp hơn cho các phép nối phức tạp và cập nhật thường xuyên.

TSDB sử dụng nén, giảm mẫu và chính sách lưu trữ để quản lý hiệu quả khối lượng dữ liệu lịch sử lớn, giúp giảm phân giải dữ liệu cũ bằng cách tổng hợp vào các khoảng thời gian thô hơn.

Điểm chính:

TSDB tối ưu cho dữ liệu có thứ tự thời gian với khả năng nhập liệu hiệu suất cao
Sử dụng các kỹ thuật nén đặc biệt (delta encoding, run-length encoding)
Tự động quản lý vòng đời dữ liệu với chính sách lưu trữ và giảm mẫu
Phù hợp cho giám sát hạ tầng và xử lý dữ liệu IoT
Vượt trội hơn cơ sở dữ liệu quan hệ cho ghi tần suất cao và truy vấn theo thời gian

How Memory Maps (mmap) Deliver 25x Faster File Access in Go

Bài viết trình bày về cơ chế sơ đồ bộ nhớ (mmap) trong Unix, cho phép xử lý tệp như một phần của bộ nhớ ảo. Thay vì sử dụng thao tác tìm kiếm/đọc truyền thống, mmap cung cấp con trỏ trực tiếp đến dữ liệu tệp trong bộ nhớ.

Các bài kiểm tra hiệu suất cho thấy:

Tra cứu ngẫu nhiên (ReaderAt): 416.4 ns/op
Tra cứu ngẫu nhiên (mmap): 3.3 ns/op
Lặp lại (ReaderAt): 333.3 ns/op
Lặp lại (mmap): 1.3 ns/op

Đối với ghi dữ liệu, mmap kém hiệu quả hơn do lỗi trang, với thời gian 1870 ns/op khi trang chưa được ánh xạ. Tác giả đã ứng dụng mmap trong hệ thống tệp HTTP, đạt được cải thiện hiệu suất 25 lần, giúp giảm đáng kể áp lực bộ nhớ và độ trễ.

Mặc dù có hạn chế khi ghi, mmap vẫn là giải pháp tối ưu cho các ứng dụng yêu cầu tốc độ truy cập tệp cao.

Điểm chính:

mmap cho phép xử lý tệp như phần của bộ nhớ ảo trong Unix
Đạt hiệu suất 25 lần nhanh hơn phương pháp truyền thống
Hiệu quả cao cho đọc dữ liệu nhưng kém hơn khi ghi do lỗi trang
Phù hợp cho các ứng dụng yêu cầu tốc độ truy cập tệp cao
Giảm đáng kể áp lực bộ nhớ và độ trễ trong hệ thống

Bloom filters

Bloom filters là cấu trúc dữ liệu xác suất để kiểm tra thành viên tập hợp hiệu quả. Được Burton Bloom đề xuất vào năm 1970, chúng hoạt động bằng cách sử dụng nhiều hàm băm để đặt các bit trong một mảng bit.

Ưu điểm chính:

Không bao có kết quả âm giả
Hiệu quả về mặt không gian
Thời gian tìm kiếm hằng số
Đặc biệt hữu ích khi hầu hết các truy vấn kiểm tra sự không thuộc về tập hợp

Nguyên lý hoạt động:

Chèn mục: Băm mục bằng k hàm băm và đặt các bit tương ứng thành 1
Kiểm tra: Nếu bất kỳ bit nào là 0, chắc chắn mục không có; nếu tất cả là 1, có thể có kết quả dương giả

Công thức tối ưu:

Tỷ lệ bit trên phần tử: m/n ≈ -ln(ε)/ln²(2)
Số hàm băm tối ưu: k = (m/n)·ln(2)

Ví dụ thực tế: Với 1 tỷ mục và tỷ lệ lỗi 1%, cần khoảng 1.2GB không gian.

Điểm chính:

Bloom filters là cấu trúc dữ liệu xác suất cho kiểm tra thành viên tập hợp
Sử dụng nhiều hàm băm để đặt bit trong mảng bit
Có thể có kết quả dương giả nhưng không bao có kết quả âm giả
Hiệu quả về mặt không gian và thời gian tìm kiếm hằng số
Phù hợp cho các hệ thống yêu cầu kiểm tra nhanh sự không thuộc về tập hợp

What the heck is AEAD again?

AEAD là tiêu chuẩn mã hóa hiện đại, kết hợp mã hóa xác thực và dữ liệu liên kết. Giải pháp này đảm bảo bảo vệ cả thông điệp mã hóa và dữ liệu không mã hóa đi kèm, ngăn chặn tấn công thay đổi nội dung. Thay vì thực hiện riêng biệt như trước, thư viện mã hóa hiện đại như libsodium cung cấp API đơn giản, giảm thiểu lỗi. Các thuật toán phổ biến gồm AES256-GCM và ChaCha20-Poly1305, nhưng việc lựa chọn nên dựa trên yêu cầu cụ thể của hệ thống.

Điểm chính:

AEAD kết hợp mã hóa xác thực và dữ liệu liên kết trong một giải pháp duy nhất
Đảm bảo bảo vệ cả thông điệp mã hóa và dữ liệu không mã hóa đi kèm
Ngăn chặn tấn công thay đổi nội dung (tampering)
Thư viện hiện đại như libsodium cung cấp API đơn giản, giảm thiểu lỗi
Các thuật toán phổ biến: AES256-GCM và ChaCha20-Poly1305

Ceilometer: Khung đo lường thích ứng của Uber

Ceilometer là khung đo lường thích ứng của Uber, được thiết kế để hỗ trợ quyết định cơ sở hạ tầng và duy trì tiêu chuẩn hiệu suất cao. Hệ thống này có khả năng hoạt động trên nhiều khung kiểm thử khác nhau, bao gồm cả kiểm thử tổng hợp (synthetic), có trạng thái (stateful) và không trạng thái (stateless).

Ứng dụng chính:

Định hình (shape qualification): Đánh giá các loại máy chủ mới, từ giai đoạn phát triển của nhà cung cấp đến triển khai thực tế trong môi trường Uber.
Xác minh thay đổi (change validation): Đánh giá bất kỳ thay đổi nào đối với cơ sở hạ tầng hiện có, hợp tác với chủ sở hữu dịch vụ để đảm bảo hiệu suất chính xác.

Triển khai trong tương lai:

Tích hợp AI/ML sâu hơn
Hỗ trợ hệ sinh thái rộng hơn
Phát hiện bất thường tiên tiến
Tích hợp chỉ số sử dụng thành phần
Kiểm tra xác định liên tục

Ceilometer đã đáp ứng nhu cầu đo lường thích ứng của Uber, thể hiện khả năng thích nghi với các yếu tố quan trọng, và tiếp tục phát triển để đáp ứng các yêu cầu đo lường tiên tiến tại Uber.

Điểm chính:

Ceilometer hỗ trợ quyết định cơ sở hạ tầng và duy trì tiêu chuẩn hiệu suất cao
Hoạt động trên nhiều khung kiểm thử khác nhau (synthetic, stateful, stateless)
Hai ứng dụng chính: định hình máy chủ mới và xác minh thay đổi cơ sở hạ tầng
Tích hợp với chủ sở hữu dịch vụ để đảm bảo hiệu suất chính xác
Tiếp tục phát triển với các tính năng AI/ML và phát hiện bất tiên tiến

Useful patterns for building HTML tools

Bài viết trình bày các mẫu hữu ích để xây dựng công cụ HTML - ứng dụng kết hợp HTML, JavaScript và CSS trong một tệp duy nhất. Tác giả đã phát triển hơn 150 công cụ như vậy trong hai năm qua, chủ yếu do LLM viết.

Các điểm chính bao gồm:

Kiến trúc cơ bản: một tệp duy nhất, không sử dụng React, tải phụ thuộc từ CDN
Tạo mẫu với Artifacts hoặc Canvas
Sử dụng localStorage để lưu trạng thái hoặc bí mật
Tận dụng API có CORS và WebAssembly
Xây dựng công cụ gỡ lỗi để khám phá khả năng
Phối hợp lại các công cụ trước đó

Bài viết khuyến khích người đọc bắt đầu xây dựng bộ sưu tập công cụ riêng, sử dụng GitHub Pages để lưu trữ và chia sẻ.

Điểm chính:

Công cụ HTML là ứng dụng kết hợp HTML, JavaScript và CSS trong một tệp duy nhất
Kiến trúc đơn giản: một tệp, không React, phụ thuộc từ CDN
Tận dụng localStorage, API có CORS và WebAssembly
Tác giả đã phát triển hơn 150 công cụ như vậy trong hai năm
Khuyến khích bắt đầu xây dựng bộ sưu tập công cụ riêng và chia sẻ trên GitHub Pages

Memory Allocation in Go

Bài viết này phân tích chi tiết cơ chế phân bổ bộ nhớ trong Go, một chủ đề quan trọng để tối ưu hiệu suất ứng dụng. Go sử dụng hệ thống phân cấp với ba thành phần chính: mheap (quản lý bộ nhớ toàn cục), mcentral (trung tâm phân bổ span) và mcache (bộ đệm bộ nhớ trên mỗi processor P).

Go chia đối tượng thành ba loại dựa trên kích thước: tiny (<16 bytes), small (16-32760 bytes) và large (>32760 bytes). Mỗi loại có cách phân bổ riêng biệt. Tiny objects được xử lý hiệu quả bằng allocator chuyên dụng, trong khi small objects được quản lý qua các span với 68 size class khác nhau. Large objects được phân bổ trực tiếp từ mheap.

Stack của goroutine cũng được quản lý linh hoạt, bắt đầu với 2KB và có thể tăng gấp đôi khi cần thiết. Go sử dụng cơ chế contiguous stacks để tránh vấn đề performance của segmented stacks.

Phân tích escape analysis quyết định biến nên được phân bổ trên stack hay heap, đảm bảo an toàn bộ nhớ. Các nghiên cứu tình huống cho thấy cách tối ưu như tái sử dụng slice, nhóm biến thành struct và dùng sync.Pool để giảm số lần phân bổ bộ nhớ.

Hiểu rõ cơ chế này giúp developer viết mã hiệu quả hơn và tránh các vấn đề về hiệu suất liên quan đến quản lý bộ nhớ.

Điểm chính:

Go sử dụng hệ thống phân cấp ba cấp: mheap, mcentral và mcache
Đối tượng chia thành three loại: tiny (<16B), small (16-32760B) và large (>32760B)
Tiny objects dùng allocator chuyên dụng, small objects quản lý qua span
Stack goroutine bắt đầu 2KB, tăng gấp đôi khi cần
Escape analysis quyết định stack/heap allocation
Tối ưu: tái sử dụng slice, group variables, dùng sync.Pool

System Design Masterclass: Building a Global CDN and Edge Caching Strategy

Bài viết hướng dẫn cách thiết kế mạng phân phối nội dung (CDN) toàn cầu và chiến lược caching tại edge để cung cấp nội dung với tốc độ ánh sáng trên toàn thế giới. CDN hoạt động như một mạng lưới máy chủ phân phối toàn cầu, lưu trữ bản sao nội dung từ máy chủ gốc và phân phối cho người dùng từ vị trí gần nhất.

Nguyên tắc hoạt động chính:

Đưa nội dung gần với người dùng
Giảm độ trễ và tải cho máy chủ gốc
Cải thiện tốc độ tải trang và trải nghiệm người dùng
Bảo vệ khỏi các tấn công DDoS

Các yếu tố quan trọng khi thiết kế CDN:

Phân loại nội dung: static (hình ảnh, CSS/JS, video) và dynamic (API response, trang cá nhân hóa)
Cấu hình TTL (Time-to-Live) cho từng loại nội dung
Xử lý cache invalidation khi nội dung cập nhật
Sử dụng anycast network để định tuyến thông minh
Tích hợp với SSL offloading và DDoS protection

Chiến lược caching hiệu quả:

Cache static assets với TTL dài (tuần/tháng)
Sử dụng micro-caching cho dynamic content (vài giây/phút)
Kết hợp TTL expiry, manual purge và versioning
Giám sát cache hit ratio để tối ưu hóa

Điểm chính:

CDN là mạng lưới máy phân phối nội dung toàn cầu, giảm độ trễ bằng cách lưu cache tại edge
Phân loại nội dung static/dynamic để áp dụng chiến lược caching phù hợp
TTL expiry, manual purge và versioning là ba phương pháp chính cho cache invalidation
Anycast network giúp định tuyến người dùng đến server gần nhất
Giám sát và tối ưu liên tục là chìa khóa để CDN hoạt động hiệu quả

Protect Your API: A Developer’s Guide to Rate Limiting and Throttling

Bài viết cung cấp hướng dẫn toàn diện về rate limiting và throttling để bảo vệ API khỏi các tấn công và quá tải. Trong kỹ thuật phần mềm, một sự thật cơ bản là tài nguyên là hữu hạn. Mọi hệ thống đều có điểm giới hạn, và nếu không có cơ chế kiểm soát, một đợt tăng traffic đột ngột có thể làm sập toàn bộ hệ thống.

Rate limiting là cơ chế quản lý luồng dữ liệu, đặt giới hạn về số lần một người dùng có thể thực hiện hành động trong một khoảng thời gian nhất định. Giống như giới tốc độ trên đường cao tốc, nó ngăn chặn xe (dữ liệu) đi quá nhanh gây tai nạn (máy chủ bị crash).

Các ứng dụng chính:

Ngăn chặn tấn công DDoS bằng cách phát hiện và chặn các địa chỉ IP gửi lượng yêu cầu bất thường
Quản lý tài nguyên và chi phí, đảm bảo công bằng giữa các người dùng
Ngăn chặn tấn công brute force bằng giới hạn số lần thử đăng nhập

Điểm chính:

Rate limiting là thành phần quan trọng trong việc xây dựng hệ thống phân tán đáng tin cậy
Ba thuật toán phổ biến: Token Bucket (cho phép traffic đột phá), Leaky Bucket (luồng ổn định), Fixed Window, Sliding Window
HTTP status code 429 Too Many Requests được dùng khi bị rate limit
Cần cân bằng giữa bảo mật và trải nghiệm người dùng
Triển khai tại application layer hoặc middleware layer

ACID vs BASE: The System Design Interview

Bài viết giải thích sự khác biệt cơ bản giữa hai triết lý thiết kế cơ sở dữ liệu: ACID và BASE - sự đánh đổi giữa tốc độ và độ tin cậy trong các hệ thống phần mềm lớn.

Mỗi hệ thống lớn phải cân bằng hai yếu tố đối lập: tốc độ và độ tin cậy. Khi thiết kế cơ sở dữ liệu, bạn buộc phải chọn một triết lý: hệ thống là một người hoàn hảo khắt khe đảm bảo tính chính xác tuyệt đối ngay cả khi có nghĩa là chậm lại, hay một hệ thống linh hoạt và cực nhanh ngay cả khi có nghĩa là dữ liệu không được đồng bộ hóa hoàn hảo trong vài giây?

ACID (Người Hoàn Hảo Khắt Khe) Là tiêu chuẩn vàng cho cơ sở dữ liệu quan hệ trong nhiều thập kỷ. ACID ưu tiên tính nhất quán và an toàn trên hết.

Atomicity: Hoàn toàn hoặc không gì cả - giao dịch được xử lý như một đơn vị duy nhất
Consistency: Tuân thủ quy tắc - đảm bảo dữ liệu chuyển từ trạng thái hợp lệ sang trạng thái hợp lệ khác
Isolation: Chờ lượt - các giao dịch đồng thời không can thiệp vào nhau
Durability: Viết bằng đá - dữ liệu được cam kết sẽ tồn tại vĩnh viễn

Hạn chế của ACID là khó mở rộng ngang (horizontal scaling) khi dữ liệu được phân tán trên nhiều máy chủ.

BASE (Triết lý cho Big Data) Được tạo ra cho kỷ nguyên Big Data và hệ thống phân tán, thường được sử dụng bởi NoSQL databases.

Basically Available: Hệ thống luôn sẵn sàng cung cấp phản hồi
Soft State: Trạng thái hệ thống có thể thay đổi theo thời gian ngay cả khi không có đầu vào mới
Eventual Consistency: Dữ liệu sẽ đồng bộ hóa cuối cùng

Khi nào nên dùng từng triết lý:

ACID: Hệ thống tài chính, quản lý kho, hồ sơ y tế (nơi tính chính xác là quan trọng)
BASE: Mạng xã hội, phân tích thời gian thực, phân phối nội dung (nơi tốc độ và khả năng mở rộng quan trọng)

Điểm chính:

ACID là bi quan: giả định mọi thứ sẽ vỡ nên khóa mọi thứ lại
BASE là lạc quan: giả định mọi thứ sẽ ổn định nên tiếp tục chạy nhanh
Sự đánh đổi: bạn thường đánh đổi tính nhất quán ngay lập tức để có sẵn cao và hiệu suất
Quy tắc quyết định: “Nếu dữ liệu sai 2 giây, có ai mất tiền không?” - Nếu có thì dùng ACID, nếu không thì BASE

Hash tables in Go and advantage of self-hosted compilers

Bài viết khám phá cách Go triển khai bảng băm (hash table), tập trung vào hiệu quả sử dụng bộ nhớ khi sử dụng map[int]struct{} so với map[int]bool để theo dõi các giá trị duy nhất.

Go thiếu cấu trúc dữ liệu set tích hợp, vì vậy các nhà phát triển sử dụng hash maps để tạo set. Trong các phiên bản trước Go 1.24, việc sử dụng struct{} giúp tiết kiệm bộ nhớ bằng cách bỏ qua phần giá trị. Tuy nhiên, với Tables Swiss trong Go 1.24, cả hai cách tiếp cận đều có mức sử dụng bộ nhớ giống hệt nhau.

Điểm thú vị về lưu trữ bộ nhớ:

“Các struct cần padding để đảm bảo căn chỉnh bộ nhớ đúng cách”
“Lượng bộ nhớ mà một struct sử dụng không luôn bằng tổng của các trường của nó”

Bài viết cũng đề cập đến LLM có thể cung cấp thông tin không cập nhật về tối ưu hóa hash table của Go. Trình biên dịch tự托管 (self-hosted) của Go cho phép kiểm tra các chi tiết triển khai, giúp các nhà phát triển hiểu rõ hơn về cách thức hoạt động thực sự của các cấu trúc dữ liệu bên trong.

Điểm chính:

Go thiếu set data structure tích hợp, nên dùng hash maps thay thế
Go 1.24 với Swiss Tables làm cho cả map[int]struct{} và map[int]bool có cùng mức sử dụng bộ nhớ
Yêu cầu căn chỉnh bộ nhớ có thể ảnh hưởng đến tối ưu hiệu suất
Cần cân nhắc tính đọc khi chọn giữa bool và struct{} implementations
Trình biên dịch tự托管 của Go giúp kiểm tra chi tiết triển khai

Gist of Go: Concurrency

Một cuốn sách tương tác dạy lập trình đồng thời trong Go thông qua bài tập thực hành, nhắm đến các lập trình viên đã quen thuộc với cơ bản Go. Cuốn sách bao gồm các nguyên lý đồng thời, kỹ thuật đồng bộ hóa và cách tiếp cận kiểm thử với hơn 50 bài tập tự động kiểm tra.

Điểm khác biệt của cuốn sách này là nó không chỉ giới thiệu về goroutine, channel và select, mà tập trung vào việc giúp người đọc thực sự hiểu và áp dụng các nguyên lý đồng thời. Mỗi bài tập đều đủ đơn giản để có thể giải quyết với một trang mã nhưng lại sát với các kịch bản thực tế.

Nội dung chính:

Phần 1: Nguyên lý cơ bản - Goroutines, Channels, Pipelines, Time, Context
Phần 2: Đồng bộ hóa - Wait groups, Data races, Race conditions, Semaphores, Signaling, Atomics
Phần 3: Các chủ đề khác - Testing, Internals

Đặc điểm nổi bật:

500+ ví dụ tương tác
50 bài tập tự động kiểm tra (có lời giải)
PDF 448 trang
Nội dung 100% gốc, không phải do AI tạo ra

Tác giả Anton Zhiyanov đã dựa trên khóa học Go concurrency của mình (250 học viên, đánh giá 5 sao) để tạo ra cuốn sách này, giúp người học nắm vững lập trình đồng thời trong Go một cách thực tế.

Điểm chính:

Tập trung vào hiểu và áp dụng thực tế chứ không chỉ lý thuyết
Bài tập đơn giản nhưng sát với thực tế
Kết hợp giữa giải thích rõ ràng và ví dụ cụ thể
Hỗ trợ đọc trực tuyến và tải PDF
Phù hợp cho lập trình viên đã biết cơ bản Go

The State of AI Coding 2025 | Greptile

Báo cáo này là một nghiên cứu đa ngành về các xu hướng gần đây trong phát triển phần mềm AI, khám phá tốc độ đội kỹ sư, việc áp dụng công cụ AI, xu hướng tăng trưởng mô hình và điểm chuẩn hiệu suất.

Greptile đã thực hiện nghiên cứu này để cung cấp cái nhìn toàn cảnh về trạng thái hiện tại của lập trình AI vào năm 2025. Báo cáo tập trung vào các khía cạnh chính:

Tốc độ đội kỹ sư (Engineering Team Velocity) Các công cụ AI đang thay đổi cách các đội kỹ sư làm việc, giúp tăng tốc độ phát triển và cải thiện chất lượng mã nguồn. Nghiên cứu có thể phân tích mức độ cải thiện về thời gian hoàn thành công việc và giảm lỗi.

Việc áp dụng công cụ AI (AI Tool Adoption) Xu hướng sử dụng các công cụ AI trong phát triển phần mềm đang tăng mạnh. Báo cáo có thể đưa ra số liệu thống kê về tỷ lệ sử dụng các công cụ AI IDE, trợ lý lập trình và các nền tảng code review tự động.

Xu hướng tăng trưởng mô hình (Model Growth Trends) Các mô hình AI lớn đang phát triển nhanh chóng về cả quy mô và khả năng. Nghiên cứu có thể so sánh các mô hình khác nhau về hiệu suất, chi phí và ứng dụng thực tế.

Điểm chuẩn hiệu suất (Performance Benchmarks) Đánh giá hiệu suất của các giải pháp AI coding thông qua các chỉ số như độ chính xác, tốc độ xử lý và khả năng hiểu ngữ cảnh của codebase.

Báo cáo này cung cấp dữ liệu quý giá cho các nhà phát triển, quản lý dự án và các tổ chức muốn hiểu rõ hơn về cách AI đang định hình tương lai của ngành phát triển phần mềm.

Điểm chính:

Nghiên cứu đa ngành về các xu hướng AI trong phát triển phần mềm
Tập trung vào tốc độ đội kỹ sư, adoption rate, và hiệu suất mô hình
Cung cấp điểm chuẩn và số liệu thống kê thực tế
Giúp các tổ chức hiểu rõ tác động của AI đến quy trình phát triển
Định hướng cho các chiến lược áp dụng AI coding tools

Bonus

Images

Đánh giá: Tốc độ xử lý urls rất chậm, mình mất cực nhiều thời gian so với trước kia để xử lý 1 url. Tóm tắt khi ngắn khi dài, lại còn đôi khi lẫn lộn kí tự tiếng Trung vào nữa (có vẻ là do model của Z.AI)

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #8

Mon, 24 Mar 2025 00:00:00 +0700

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

Let’s deadlock all the things

Bài viết của Michael Simons kể về một lỗi “rookie” mà ông gặp phải khi làm việc với Java HttpClient, cho thấy rằng ngay cả những lập trình viên có kinh nghiệm cũng có thể mắc những lỗi cơ bản.

Tác giả đang cố gắng chuyển đổi code từ HttpURLConnection cũ sang HttpClient mới của Java. Trong quá trình này, ông đã cố gắng sử dụng PipedInputStream và PipedOutputStream để xử lý request body, bỏ qua cảnh báo trong JavaDoc về việc sử dụng cả hai đối tượng trong cùng một thread có thể gây deadlock.

Mặc dù code “hoạt động” trong các test cơ bản, nhưng khi xử lý payload lớn hơn buffer mặc định (1024 bytes), hệ thống sẽ bị deadlock và có thể làm cạn kiệt tất cả các thread có sẵn.

Tác giả chia sẻ một số bài học rút ra:

Đọc kỹ tài liệu và không bỏ qua các cảnh báo
Cần có góc nhìn thứ hai từ đồng nghiệp
Test kỹ hơn, đặc biệt là các trường hợp biên
AI có thể giúp tạo test input, nhưng không thể thay thế việc hiểu sâu về API

Cuối cùng, tác giả đã tìm ra giải pháp bằng cách sử dụng virtual thread để xử lý việc ghi dữ liệu, tránh deadlock và cho phép xử lý payload lớn một cách hiệu quả.

Engineers who won’t commit

Bài viết của Sean Goedecke thảo luận về một vấn đề phổ biến trong giới kỹ sư phần mềm: việc không dám đưa ra quan điểm trong các cuộc thảo luận kỹ thuật. Tác giả cho rằng mặc dù việc giữ thái độ “cởi mở” và “không cam kết” có thể phù hợp với kỹ sư mới vào nghề, nhưng khi bạn là người có nhiều kinh nghiệm nhất trong phòng họp, bạn cần phải đưa ra quan điểm của mình, ngay cả khi chỉ tự tin 55-60%.

Tác giả chỉ ra rằng việc không đưa ra quan điểm có thể dẫn đến những hậu quả tiêu cực:

Buộc những người ít kinh nghiệm hơn phải tự quyết định
Có thể dẫn đến việc người kém nhất nhưng nói to nhất trong nhóm đưa ra quyết định tồi
Tạo gánh nặng cho quản lý khi họ phải đưa ra quyết định kỹ thuật thay vì kỹ sư

Tuy nhiên, tác giả cũng thừa nhận rằng có những trường hợp ngoại lệ hợp lý, đặc biệt là trong môi trường làm việc độc hại nơi các kỹ sư có thể bị trừng phạt vì đưa ra ước tính không chính xác.

Bài viết kết luận rằng việc đưa ra quan điểm là trách nhiệm của kỹ sư có kinh nghiệm, và việc không làm điều đó có thể được coi là một dạng hèn nhát. Điều quan trọng là phải phân biệt giữa việc đưa ra quan điểm trong môi trường làm việc và việc giữ thái độ cởi mở trong các cuộc thảo luận với đồng nghiệp có cùng trình độ.

Patterns for building realtime features

Bài viết của Zach Knill giới thiệu các mẫu thiết kế phổ biến để xây dựng tính năng realtime trong ứng dụng. Các tính năng realtime giúp ứng dụng cảm giác hiện đại, có tính cộng tác và luôn được cập nhật kịp thời.

Tác giả giới thiệu 4 mẫu thiết kế chính:

Poke/Pull: Server gửi thông báo (“poke”) cho các client đã đăng ký khi có thay đổi, sau đó client sẽ tự động kéo (“pull”) dữ liệu mới. Mẫu này dễ tích hợp vào ứng dụng hiện có nhưng có thể gây tải cho server do nhiều client cùng kéo dữ liệu.
Push state: Server trực tiếp đẩy trạng thái mới đến client thay vì chỉ gửi thông báo. Mẫu này giải quyết vấn đề tải server nhưng có thể không hiệu quả khi trạng thái lớn hoặc khi client cần biết chính xác điều gì đã thay đổi.
Push operations: Server gửi các thao tác thay đổi thay vì toàn bộ trạng thái. Mẫu này giúp client biết chính xác điều gì đã thay đổi và giảm lượng dữ liệu truyền tải, nhưng yêu cầu client phải có logic để áp dụng các thao tác.
Event sourcing: Server gửi các sự kiện đã xảy ra thay vì các thao tác. Mẫu này cho phép client có logic phức tạp hơn nhưng yêu cầu client phải hiểu ý nghĩa của mỗi sự kiện.

Tác giả cũng thảo luận về các phương thức vận chuyển (transports) như WebSocket, SSE, và các thách thức khi triển khai trong hệ thống phân tán. Trong môi trường có nhiều server replica, việc đồng bộ trạng thái giữa các client kết nối với các server khác nhau có thể phức tạp, và các dịch vụ Pub/Sub có thể giúp giải quyết vấn đề này.

Optimizing the databases at Quora

Bài viết từ đội ngũ kỹ sư Quora chia sẻ chi tiết về quá trình tối ưu hóa cơ sở dữ liệu của họ. Quora đã phải đối mặt với nhiều thách thức khi hệ thống phát triển, bao gồm việc xử lý lượng lớn dữ liệu và đảm bảo hiệu suất cho người dùng.

Các chiến lược tối ưu chính bao gồm:

Phân mảnh dữ liệu (Sharding): Quora đã triển khai sharding để phân phối tải trên nhiều máy chủ cơ sở dữ liệu. Họ sử dụng một chiến lược sharding dựa trên user_id, cho phép họ phân phối dữ liệu người dùng một cách hiệu quả.
Tối ưu hóa truy vấn: Đội ngũ đã phân tích và tối ưu các truy vấn phổ biến, thêm các chỉ mục phù hợp và loại bỏ các truy vấn không cần thiết.
Caching: Quora triển khai nhiều lớp cache khác nhau:
- Cache ở cấp độ ứng dụng cho dữ liệu thường xuyên truy cập
- Cache ở cấp độ cơ sở dữ liệu cho các kết quả truy vấn phổ biến
- Sử dụng Memcached cho cache phân tán
Đọc/ghi phân tách (Read/Write Splitting): Hệ thống được thiết kế để phân tách các hoạt động đọc và ghi, cho phép mở rộng độc lập các khả năng đọc và ghi.
Giám sát và cảnh báo: Quora đã xây dựng hệ thống giám sát toàn diện để theo dõi hiệu suất cơ sở dữ liệu và phát hiện sớm các vấn đề.

Bài viết cũng nhấn mạnh tầm quan trọng của việc:

Thường xuyên phân tích và tối ưu hóa hiệu suất
Xây dựng các công cụ tự động hóa cho việc quản lý cơ sở dữ liệu
Duy trì sự cân bằng giữa hiệu suất và tính đơn giản của hệ thống

Failure Mitigation for Microservices: An Intro to Aperture

Bài viết từ đội ngũ DoorDash giới thiệu về Aperture, một hệ thống quản lý độ tin cậy mã nguồn mở mà họ đã phát triển để giải quyết các vấn đề phổ biến trong kiến trúc microservices.

Aperture được thiết kế để giải quyết 3 thách thức chính:

Cascading Failures: Lỗi lan truyền từ service này sang service khác
Retry Storms: Các request thất bại được thử lại nhiều lần
Death Spirals: Lỗi lan truyền ngang trong cùng một service

Hệ thống hoạt động theo 3 bước chính:

Collect: Thu thập metrics từ các node (CPU, memory, latency, error rate) thông qua sidecar và tổng hợp trong Prometheus
Analyze: Controller giám sát metrics và theo dõi các sai lệch so với service-level objectives (SLO) được định nghĩa trong file YAML
Actuate: Khi các policy được kích hoạt, Aperture sẽ thực hiện các hành động như load shedding hoặc rate limiting phân tán

DoorDash đã triển khai Aperture trong một service chính và thử nghiệm với các request nhân tạo. Kết quả cho thấy nó hoạt động như một global rate limiter và load shedder mạnh mẽ, dễ sử dụng.

Bài viết cũng nhấn mạnh tầm quan trọng của việc:

Thiết lập SLO rõ ràng cho mỗi service
Giám sát liên tục và phát hiện sớm các vấn đề
Tự động hóa việc xử lý các sự cố
Duy trì tính đơn giản của hệ thống

Zero Configuration Service Mesh with On-Demand Cluster Discovery

Bài viết từ đội ngũ Netflix chia sẻ về hành trình chuyển đổi sang service mesh và cách họ giải quyết thách thức về cấu hình cluster trong môi trường microservices phức tạp.

Netflix đã sớm chuyển sang cloud, bắt đầu từ năm 2008 và hoàn thành vào năm 2010. Trong giai đoạn đầu, họ đã xây dựng các công cụ riêng như Eureka cho service discovery và Ribbon cho IPC (Inter-Process Communication). Tuy nhiên, khi hệ thống phát triển, họ gặp phải nhiều thách thức mới:

Hỗ trợ nhiều loại IPC client khác nhau (REST, GraphQL, gRPC)
Môi trường đa ngôn ngữ (Java, Node.js, Python)
Nhu cầu về các tính năng phức tạp như adaptive concurrency limiting, circuit breaking

Để giải quyết các vấn đề này, Netflix quyết định chuyển sang sử dụng service mesh với Envoy làm proxy. Tuy nhiên, họ gặp phải thách thức về việc cấu hình cluster: mỗi service có thể cần giao tiếp với hàng chục cluster khác nhau, và danh sách này thay đổi liên tục.

Netflix đã hợp tác với Kinvolk và cộng đồng Envoy để phát triển tính năng On-Demand Cluster Discovery (ODCDS). Với tính năng này, proxy có thể tìm kiếm thông tin cluster khi cần thiết, thay vì phải định nghĩa trước tất cả các cluster trong cấu hình.

Quy trình hoạt động:

Request đến Envoy
Kiểm tra cluster đích dựa trên header
Nếu cluster chưa tồn tại, tạm dừng request
Yêu cầu thông tin cluster từ control plane
Nhận thông tin cluster và endpoints
Tiếp tục xử lý request

Lợi ích chính:

Không cần cấu hình trước các cluster
Giảm độ phức tạp của hệ thống
Tiết kiệm bộ nhớ bằng cách chỉ tải thông tin cluster cần thiết
Dễ dàng chuyển đổi từ hệ thống cũ sang service mesh

Tuy nhiên, cũng có một số nhược điểm:

Thêm độ trễ cho request đầu tiên đến một cluster
Có thể không phù hợp với các service yêu cầu độ trễ rất thấp

Netflix vẫn đang trong giai đoạn đầu của hành trình service mesh và đang tiếp tục cải thiện hệ thống, đặc biệt là trong việc tối ưu hóa EDS (Endpoint Discovery Service).

The Quest to Understand Metric Movements

Bài viết từ đội ngũ Pinterest chia sẻ về cách họ xây dựng hệ thống phân tích nguyên nhân gốc rễ (Root Cause Analysis - RCA) cho các chuyển động của metrics. Khi một metric quan trọng có sự thay đổi bất thường, việc tìm ra nguyên nhân có thể rất phức tạp do có nhiều yếu tố có thể ảnh hưởng.

Pinterest đã phát triển ba phương pháp tiếp cận chính:

Slice and Dice: Phân tích chi tiết các phân đoạn của metric để tìm manh mối về nguyên nhân thay đổi. Ví dụ, khi phân tích tỷ lệ xem video, họ có thể chia nhỏ theo các chiều như quốc gia, loại thiết bị, loại Pin, v.v. Phương pháp này đặc biệt hiệu quả trong việc chẩn đoán các vấn đề về metrics video.
General Similarity: Tìm kiếm các metrics khác có chuyển động tương tự trong cùng khoảng thời gian. Hệ thống sử dụng bốn yếu tố để đo lường độ tương đồng:
- Pearson correlation: đo mối quan hệ tuyến tính
- Spearman’s rank correlation: đo mối quan hệ đơn điệu
- Euclidean similarity: dựa trên khoảng cách Euclidean
- Dynamic time warping: cho phép so sánh các chuỗi thời gian có độ dài khác nhau
Experiment Effects: Phân tích tác động của các thử nghiệm A/B testing lên metrics. Hệ thống sẽ:
- Tính toán tác động của mỗi thử nghiệm lên metric
- Sử dụng Welch’s t-test để đánh giá ý nghĩa thống kê
- Lọc các thử nghiệm dựa trên p-value và sự mất cân bằng giữa nhóm kiểm soát và nhóm thử nghiệm

Các phương pháp này có thể được sử dụng kết hợp với nhau để thu hẹp phạm vi tìm kiếm nguyên nhân. Pinterest đang tiếp tục cải thiện hệ thống bằng cách:

Thêm cơ chế phản hồi từ người dùng
Tích hợp với các nền tảng dữ liệu khác
Khám phá các mối quan hệ nhân quả giữa các metrics
Tích hợp RCA vào các công cụ khám phá và trực quan hóa dữ liệu

Meta’s Hyperscale Infrastructure: Overview and Insights

Bài viết từ Chunqiang Tang của Meta chia sẻ tổng quan về cơ sở hạ tầng hyperscale của công ty và những bài học kinh nghiệm từ quá trình phát triển. Mặc dù hầu hết các kỹ sư không trực tiếp xây dựng cơ sở hạ tầng hyperscale, việc hiểu về nó rất có ích vì nhiều công nghệ phổ biến ngày nay đã bắt nguồn từ môi trường này.

Các điểm chính về văn hóa kỹ thuật của Meta:

Move fast: Tập trung vào việc triển khai nhanh và lặp lại liên tục:
- Triển khai liên tục code mới nhất vào production
- Sử dụng serverless functions cho các sản phẩm
- Cho phép các team nhanh chóng thay đổi ưu tiên
Technology openness:
- Sử dụng monorepo cho tất cả dự án
- Không áp dụng quy tắc sở hữu code nghiêm ngặt
- Đóng góp nhiều dự án mã nguồn mở (PyTorch, Llama, Presto, RocksDB)
Research in production:
- Không có phòng nghiên cứu riêng biệt
- Các team phát triển sản phẩm trực tiếp thực hiện nghiên cứu
- Đảm bảo các giải pháp hoạt động ở quy mô lớn
Common infrastructure:
- Chuẩn hóa phần cứng (một loại server duy nhất cho non-AI workloads)
- Tối ưu hóa ứng dụng cho phần cứng thay vì ngược lại
- Tập trung vào tối ưu hóa toàn cục thay vì cục bộ

Chiến lược AI của Meta bao gồm:

Thiết kế đồng bộ toàn bộ stack từ PyTorch đến AI accelerators
Tối ưu hóa mạng và các mô hình ML như Llama
Tích hợp chặt chẽ giữa phần cứng và phần mềm

Bài viết cũng nhấn mạnh tầm quan trọng của việc:

Duy trì sự cân bằng giữa tốc độ phát triển và độ ổn định
Tập trung vào việc tối ưu hóa toàn cục
Đầu tư vào nghiên cứu và phát triển các công nghệ mới
Chia sẻ kiến thức và công nghệ với cộng đồng

Incremental Platforms: Monolithic Modular Architecture

Bài viết của Marcos F. Lobo giới thiệu về kiến trúc Monolithic Modular, một cách tiếp cận để xây dựng nền tảng có khả năng phát triển bền vững. Kiến trúc này kết hợp sự đơn giản của monolithic với lợi ích của thiết kế modular và tách biệt.

Đặc điểm chính của kiến trúc này:

Single Deployment: Toàn bộ code được đóng gói và triển khai như một ứng dụng duy nhất
Internal Modularization: Ứng dụng được chia thành các module hoặc component riêng biệt, mỗi module có:
- Interface rõ ràng
- Contract xác định cách giao tiếp với các module khác
- Trách nhiệm duy nhất và được định nghĩa rõ ràng

Để đạt được kiến trúc này, tác giả đề xuất các nguyên tắc:

Định nghĩa ranh giới và contract rõ ràng:
- Mỗi module phải có interface công khai
- Sử dụng các pattern như facade để tránh truy cập trực tiếp vào implementation
Tách biệt các mối quan tâm:
- Đảm bảo mỗi module có một trách nhiệm duy nhất
- Giảm thiểu sự phụ thuộc giữa các module
Tổ chức code và cấu trúc package:
- Sử dụng cấu trúc package phản ánh sự phân chia module
- Đảm bảo mỗi module có thể được tách riêng trong tương lai
Testing và tự động hóa:
- Test các use case của monolith
- Sử dụng CI/CD để kiểm tra tính toàn vẹn và giao tiếp giữa các module
Quản lý phụ thuộc và giao tiếp:
- Sử dụng dependency injection
- Xem xét sử dụng messaging hoặc events để tách biệt các module

Lợi ích chính:

Đơn giản trong triển khai và vận hành: Một artifact duy nhất, giảm overhead
Dễ dàng phát triển và refactor: Giao dịch đơn giản, truy cập tài nguyên dễ dàng
Hiệu suất và tính nhất quán: Gọi giữa các module trong bộ nhớ, xử lý giao dịch đơn giản
Hỗ trợ Domain-Driven Design: Dễ dàng chia hệ thống theo bounded contexts

Kiến trúc này đặc biệt phù hợp cho:

Dự án giai đoạn đầu
Nhóm nhỏ
Hệ thống cần tính nhất quán và toàn vẹn giao dịch
Nền tảng có thể phát triển dần dần thành kiến trúc phân tán trong tương lai

Bonus: Vài video hay ho đến từ ByteByteGo

How the Garbage Collector Works in Java, Python, and Go!

Bonus 2: Vài hình ảnh hay ho đến từ ByteByteGo

Bonus 3: Vài hình ảnh hay ho đến từ DesignGurus

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #2

Sun, 16 Feb 2025 00:00:00 +0700

Chào các bạn, đến hẹn lại lên, đây là Newsletter #2 của mình. Cuối tuần này mình đi chơi ở Xuyên Mộc, vừa về hôm nay thôi nên giờ mới lên bài.

Thôi không vòng vo nữa, vào ngay Newsletter #2 của MiTi nào.

Some things to expect in 2025

Bài viết dự đoán một số xu hướng và sự kiện có thể xảy ra trong cộng đồng Linux và phần mềm tự do năm 2025. Đầu tiên, sched-ext sẽ trở thành yếu tố thay đổi cuộc chơi, cho phép tải trình lập lịch CPU từ không gian người dùng thông qua BPF, thúc đẩy sự sáng tạo và thử nghiệm. Mã Rust sẽ được tích hợp nhiều hơn vào kernel, mang lại các tính năng mà người dùng cuối có thể không nhận ra. Bài viết cảnh báo về một nỗ lực backdoor tương tự như XZ có thể xuất hiện, và các dự án chỉ có một người duy trì sẽ bị coi là rủi ro hơn.

Một dự án lớn có thể phát hiện ra rằng họ đã hợp nhất nhiều mã do AI tạo ra mà tác giả không thực sự hiểu. Đồng thời, sẽ có nhiều nỗ lực tập trung hơn vào việc tạo ra các hệ thống AI tạo sinh thực sự tự do. Các tổ chức hỗ trợ công việc phần mềm tự do sẽ tiếp tục gặp khó khăn. Nhiều sản phẩm dựa trên đám mây sẽ trở thành “cục gạch” khi nhà sản xuất phá sản hoặc ngừng hỗ trợ. Phần cứng hoàn toàn mở sẽ trở nên phổ biến hơn, và các bản phân phối cho thiết bị di động sẽ chứng kiến sự quan tâm trở lại. Cuối cùng, bài viết nhấn mạnh rằng sự hiếu chiến toàn cầu sẽ tác động đến cộng đồng, và lời kêu gọi được đưa ra là hãy giữ vững các giá trị cốt lõi của cộng đồng trong bối cảnh chính trị phân cực.

Why you should use compact table columns

Bài viết giải thích tầm quan trọng của việc sử dụng các kiểu cột (column types) nhỏ gọn trong thiết kế cơ sở dữ liệu để tăng tốc độ truy vấn SQL. Việc sử dụng các kiểu cột nhỏ gọn cho phép lưu trữ nhiều bản ghi và mục chỉ mục hơn trong bộ nhớ cache, giúp giảm thiểu số lần truy cập đĩa. StackOverflow là một ví dụ điển hình, họ đã sử dụng chiến lược này để phục vụ hàng nghìn truy vấn mỗi giây chỉ với một máy chủ SQL duy nhất.

Bài viết chỉ ra rằng việc sử dụng các khóa chính (Primary Key) và khóa ngoại (Foreign Key) kiểu int hoặc tinyint thay vì UUID hoặc bigint, biểu diễn giá trị enum bằng 1 byte, và giới hạn độ dài của các cột VARCHAR giúp tiết kiệm không gian lưu trữ. Tác giả cũng trình bày các ví dụ cụ thể trên MySQL và PostgreSQL, cho thấy việc sử dụng các kiểu cột nhỏ gọn có thể giảm đáng kể kích thước bảng và chỉ mục, từ đó cải thiện hiệu suất truy vấn. Tuy nhiên, cần lưu ý về việc căn chỉnh cột (column alignment) trong PostgreSQL để đạt hiệu quả tối ưu. Tóm lại, việc lựa chọn kiểu cột phù hợp là một yếu tố quan trọng để tối ưu hóa hiệu suất cơ sở dữ liệu.

Rate limiting with Redis: An essential guide

Bài viết này giới thiệu về rate limiting (giới hạn tốc độ truy cập), giải thích tầm quan trọng của nó trong việc bảo vệ tài nguyên khỏi bị quá tải, ngăn chặn lạm dụng, đảm bảo truy cập công bằng, quản lý tải, giảm chi phí và bảo vệ hệ thống khỏi downtime. Redis được giới thiệu như một công cụ phổ biến để triển khai rate limiter nhờ tốc độ, độ tin cậy và các tính năng như thao tác nguyên tử, lưu trữ dữ liệu và Lua scripting.

Bài viết trình bày chi tiết các thuật toán rate limiting phổ biến: Leaky Bucket (ổn định luồng traffic), Token Bucket (xử lý các đợt tăng đột biến), Fixed Window Counter (đơn giản, độ chính xác thấp), Sliding Window Log (độ chính xác cao, tốn nhiều tài nguyên) và Sliding Window Counter (cân bằng giữa độ chính xác và hiệu quả).

Để chọn thuật toán phù hợp, cần hiểu rõ đặc điểm traffic (dự đoán được, đột biến, hỗn hợp), mức độ chính xác cần thiết, giới hạn tài nguyên (bộ nhớ, CPU, khả năng mở rộng) và trải nghiệm người dùng. Bài viết nhấn mạnh rằng rate limiting không chỉ là việc thiết lập giới hạn mà còn là thiết kế các hệ thống hiệu quả, công bằng và thân thiện với người dùng. Các triển khai cho từng loại rate limiter với Java & Redis sẽ được phát hành hàng tuần.

Why does Cloudflare Pages have such a generous Free tier?

Bài viết của Matt Sayar khám phá lý do tại sao Cloudflare Pages lại có một gói miễn phí hào phóng trong bối cảnh nhiều dịch vụ hosting hiện nay cung cấp các gói miễn phí tương tự. Cloudflare Pages nổi bật với băng thông không giới hạn, điều mà ít nền tảng nào khác có thể cạnh tranh. Các dịch vụ như GitHub Pages, GitLab Pages và Netlify đều có giới hạn băng thông, trong khi Cloudflare cho phép người dùng thoải mái phát triển trang web mà không lo lắng về chi phí phát sinh.

Tác giả cho rằng việc cung cấp băng thông không giới hạn phù hợp với chiến lược của Cloudflare trong việc phát triển một internet an toàn và nhanh chóng. Một trang web tĩnh nhẹ nhàng và dễ phục vụ, giúp Cloudflare tiết kiệm chi phí. Hơn nữa, khi người dùng trải nghiệm dịch vụ miễn phí, họ có xu hướng có ấn tượng tích cực và có thể chuyển sang sử dụng các sản phẩm trả phí của Cloudflare trong tương lai.

Bài viết cũng nhấn mạnh rằng Cloudflare đang đầu tư vào việc cải thiện internet và cung cấp nhiều dịch vụ bảo mật miễn phí, từ đó tạo ra một vòng luân chuyển lợi ích cho cả người dùng và công ty. Tác giả kết luận rằng đây là một cơ hội tốt để thử nghiệm các sản phẩm mới của Cloudflare, đặc biệt là trong thời gian gói miễn phí vẫn còn hiệu lực.

How I program with LLMs

Bài viết này tổng hợp những kinh nghiệm cá nhân của tác giả trong việc sử dụng các mô hình ngôn ngữ lớn (LLM) trong lập trình trong năm vừa qua. Tác giả nhấn mạnh rằng việc sử dụng LLM đã mang lại hiệu quả tích cực cho năng suất làm việc, và việc quay trở lại lập trình mà không có chúng trở nên khó khăn. Tác giả thường sử dụng LLM để tự động hóa các bước lặp đi lặp lại và một công cụ có tên sketch.dev đang được phát triển để hỗ trợ lập trình Go.

Có ba cách chính mà tác giả sử dụng LLM: để tự động hoàn thành code, cho các tác vụ tìm kiếm, và trong các phiên lập trình dựa trên chat. Tác giả thấy rằng LLM đặc biệt hữu ích khi anh ta biết những gì cần viết, nhưng không có đủ năng lượng để bắt đầu một file mới, tra cứu các thư viện cần thiết. LLM cung cấp bản nháp đầu tiên, thường chứa các ý tưởng hay, các dependency cần thiết và một vài lỗi. Việc sửa các lỗi này thường dễ dàng hơn là bắt đầu từ đầu.

LLM cũng rất hữu ích trong việc tạo ra các code review packet, đặc biệt là khi chúng cần sử dụng nhiều thư viện phổ biến. Tuy nhiên, cần phải biên dịch và chạy thử code do LLM tạo ra trước khi đọc kỹ, vì chúng có thể tạo ra code không biên dịch được.

Ví dụ, tác giả đã sử dụng LLM để viết một reservoir sampler cho các quartiles của các số float. LLM đã tạo ra một package có cấu trúc tốt, interface tốt và các test, nhưng code ban đầu không biên dịch được và các test chứa các giá trị sai. Tác giả đã sửa các lỗi này và sau đó yêu cầu LLM tạo ra các test tốt hơn bằng cách so sánh kết quả của reservoir sampler với một triển khai tiêu chuẩn. LLM đã tạo ra một fuzz test, nhưng nó chứa một lỗi cú pháp. Sau khi tác giả sửa lỗi này, fuzz test đã hoạt động tốt.

Nhìn chung, tác giả kết luận rằng LLM có thể là một công cụ hữu ích cho các lập trình viên, nhưng chúng không hoàn hảo và cần được sử dụng một cách cẩn thận. LLM có thể giúp cải thiện năng suất, viết test toàn diện hơn và làm cho code dễ đọc hơn.

Bonus

Tuần này có kha khá bonus đến từ nhiều nguồn khác nhau

Bonus #1: Một vài ebook mình tìm được

Bonus #2: Vài ảnh hay ho đến từ ByteByteGo

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).

Newsletter #1

Sat, 08 Feb 2025 00:00:00 +0700

Xin chào các bạn, đây lại là một lần mình quay viết blog sau chuỗi ngày lười biếng :D
Một vấn đề mình nhận ra nhưng lười sửa đổi đó là mình đọc nhiều blog, nghịch nhiều tool, nhưng không có cái nào mình thật sự nghiêm túc, đủ để viết thành một blog chất lượng cả. Nếu có gì tâm đắc thì mình cũng quá lười để viết lại.

Vì vậy mình chuyển sang thử một hình thức khác, đó là tổng hợp lại những bài blog hay mà mình đã tìm thấy, đọc được trong tuần vừa qua và tổng hợp lại thành một bản newsletter hàng tuần. Mong được mọi người ủng hộ.

Không lòng vòng nữa, sau đây là Newsletter #1 của mình.

Seconds Since the Epoch

Bài viết này giải thích lý do tại sao thời gian POSIX, thường được cho là số giây kể từ kỷ nguyên Unix (ngày 1 tháng 1 năm 1970), thực tế không chính xác như vậy. Nguyên nhân là do thời gian POSIX bắt nguồn từ Giờ Phối Hợp Quốc Tế (UTC) và tiêu chuẩn giả định rằng mỗi ngày dài đúng 86.400 giây. Tuy nhiên, độ dài của một ngày thay đổi và các nhà thiên văn học định kỳ tuyên bố giây nhuận để giữ cho ngày UTC không trôi quá xa so với ngày mặt trời. Những giây nhuận này gây ra sự gián đoạn trong thời gian POSIX. Bài viết cũng thảo luận về các giải pháp thay thế cho thời gian POSIX và nỗ lực chấm dứt giây nhuận vào năm 2035.

B-Trees: More Than I Thought I’d Want to Know

Bài đăng trên blog này đi sâu vào cấu trúc dữ liệu Cây B, đặc biệt tập trung vào việc sử dụng chúng trong các công cụ lưu trữ cơ sở dữ liệu. Nó giải thích các ràng buộc do I/O đĩa áp đặt và cách Cây B giải quyết các ràng buộc này bằng cách định vị các khóa cùng nhau trên đĩa. Bài viết thảo luận về các trang có rãnh, được sử dụng để bố trí các khóa trên đĩa để tối đa hóa vị trí và nén khóa. Nó cũng bao gồm các kỹ thuật tối ưu hóa khác nhau như cắt ngắn khóa phân tách, các trang tràn và con trỏ anh em. Cuối cùng, bài đăng trên blog đề cập đến một số biến thể Cây B và các tối ưu hóa khác có thể cung cấp các tối ưu hóa trong một số trường hợp nhất định.

SQL NULLs are Weird!

Bài viết này khám phá những hành vi kỳ lạ của giá trị NULL trong SQL, đặc biệt là cách chúng được xử lý trong các ràng buộc UNIQUE. Tác giả chỉ ra rằng, không giống như những gì người ta thường mong đợi, SQL coi tất cả các giá trị NULL là các giá trị riêng biệt. Điều này có nghĩa là một cột có ràng buộc UNIQUE có thể chứa nhiều giá trị NULL vì mỗi giá trị NULL được coi là khác với các giá trị NULL khác. Bài viết tiếp tục thảo luận về cách đảm bảo tính duy nhất khi xử lý các giá trị NULL, sử dụng các cột được tạo và lập chỉ mục một phần.

Understanding JVM Garbage Collector Performance

Bài viết này giải thích cách thức hoạt động của bộ thu gom rác (GC) trong Java Virtual Machine (JVM) và cung cấp các phương pháp cải thiện hiệu suất của nó. Tác giả bắt đầu bằng việc mô tả một GC lý thuyết đơn giản, sau đó đi sâu vào các thuật toán GC thực tế như Mark-and-Sweep và Generational Garbage Collection. Bài viết cũng thảo luận về các tham số cấu hình GC quan trọng, như kích thước heap và các tùy chọn GC khác nhau, đồng thời cung cấp các hướng dẫn về cách điều chỉnh chúng để đạt hiệu suất tối ưu. Cuối cùng, tác giả đưa ra các khuyến nghị cụ thể để cải thiện hiệu suất GC trong các dự án thực tế, bao gồm việc theo dõi và phân tích hành vi GC, cũng như điều chỉnh cấu hình GC dựa trên tải công việc cụ thể.

A Deep Dive into JVM Start-Up

Bạn có bao giờ thắc mắc điều gì xảy ra “đằng sau hậu trường” trước khi dòng lệnh System.out.println(“Hello World”) quen thuộc được thực thi trong ứng dụng Java? Video này sẽ đưa bạn vào một hành trình khám phá sâu sắc quy trình khởi động phức tạp của Java Virtual Machine (JVM). Từ việc phân tích cú pháp các tham số, kiểm tra tài nguyên hệ thống, thiết lập môi trường, đến quá trình tải, liên kết và khởi tạo lớp, bạn sẽ hiểu rõ hơn về những bước cần thiết để JVM “tạo ra vũ trụ” cho ứng dụng của bạn. Video cũng hé lộ những thay đổi thú vị trong tương lai với Project Leyden, hứa hẹn cải thiện đáng kể thời gian khởi động và hiệu suất của JVM. Đây là một tài liệu tham khảo giá trị cho bất kỳ nhà phát triển Java nào muốn nâng cao hiểu biết về nền tảng cốt lõi mà họ đang sử dụng.

Parallel processing with Virtual Threads - A comparative analysis

Bài viết này phân tích hiệu suất của việc sử dụng Virtual Threads trong xử lý song song, so sánh giữa hai cách tiếp cận: triển khai dựa trên JDK 21 và Spring Core Reactor. Tác giả bắt đầu bằng việc nêu ra các hạn chế của các luồng hệ điều hành truyền thống, như chi phí tài nguyên cao và khả năng mở rộng hạn chế. Sau đó, bài viết giới thiệu về Virtual Threads, một tính năng mới trong JDK 21, cho phép tạo ra hàng triệu luồng nhẹ với chi phí thấp, đặc biệt hiệu quả cho các tác vụ I/O. Bài viết cung cấp các ví dụ mã cho cả hai phương pháp triển khai và tiến hành phân tích so sánh dựa trên các tiêu chí như thời gian xử lý, sử dụng bộ nhớ và hoạt động của bộ thu gom rác (GC). Kết quả cho thấy, việc sử dụng Virtual Threads với triển khai dựa trên JDK mang lại hiệu suất vượt trội so với Spring Core Reactor, đặc biệt khi xử lý số lượng lớn đối tượng. Tuy nhiên, triển khai dựa trên JDK yêu cầu bộ nhớ nhiều hơn và có thời gian dừng GC dài hơn, nhưng điều này không ảnh hưởng đáng kể đến độ trễ của ứng dụng. Tác giả kết luận rằng, đối với các ứng dụng yêu cầu hiệu suất cao và khả năng mở rộng, Virtual Threads trong JDK 21 là lựa chọn ưu việt.

Bonus: Vài ảnh hay ho đến từ ByteByteGo

Bài viết đã được review và cập nhật bởi Claude Code với Opus 4.7 (1M context).