Vietnam Java User Group - Vietnam JUG, Ho Chi Minh City (2026)

13/10/2026

[English Below]
Hello mọi người!👋 Hai khách, một phòng, cùng một đêm. Đó là loại bug không ai muốn giải thích với khách hàng, và cũng chính là vấn đề mà video 𝗛𝗼𝘁𝗲𝗹 𝗥𝗲𝘀𝗲𝗿𝘃𝗮𝘁𝗶𝗼𝗻 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 này giải quyết. Video đi qua từng bước: các bảng dữ liệu, các endpoint và toàn bộ luồng booking.

Dưới đây là những điểm nổi bật:
🗝️ 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝗰𝘆 𝗞𝗲𝘆: Gửi cùng một booking request hai lần, 𝗥𝗲𝗱𝗶𝘀 vẫn nhớ key đó, nên người dùng chỉ nhận về một reservation duy nhất thay vì hai.
🏨 𝗛𝗼𝘁𝗲𝗹-𝗕𝗮𝘀𝗲𝗱 𝗦𝗵𝗮𝗿𝗱𝗶𝗻𝗴: Giữ toàn bộ dữ liệu của một khách sạn trên cùng một shard biến việc booking thành một 𝗹𝗼𝗰𝗮𝗹 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 đơn giản, không cần đến 𝘁𝘄𝗼-𝗽𝗵𝗮𝘀𝗲 𝗰𝗼𝗺𝗺𝗶𝘁.
📅 𝗣𝗲𝗿-𝗗𝗮𝘁𝗲 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆: Bảng 𝗿𝗼𝗼𝗺_𝗶𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆 theo dõi số phòng trống theo từng room type mỗi ngày, và một 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗰𝗼𝗻𝘀𝘁𝗿𝗮𝗶𝗻𝘁 sẽ chặn không cho số lượng này xuống dưới 0.
📨 𝗔𝘀𝘆𝗻𝗰 𝗢̛̉ 𝗡𝗼̛𝗶 𝗔𝗻 𝗧𝗼𝗮̀𝗻: Việc onboarding khách sạn chạy qua 𝗞𝗮𝗳𝗸𝗮 và quá trình đánh index trên 𝗘𝗹𝗮𝘀𝘁𝗶𝗰𝘀𝗲𝗮𝗿𝗰𝗵 chấp nhận 𝗲𝘃𝗲𝗻𝘁𝘂𝗮𝗹 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆, vì một kết quả search hơi cũ thì không sao, còn double booking thì không thể chấp nhận.

Nếu bạn xây dựng hệ thống trên 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁, tất cả những điều này quy về 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗣𝗔 𝗹𝗼𝗰𝗸𝗶𝗻𝗴, 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀 cho idempotency, và 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 kèm 𝗱𝗲𝗮𝗱 𝗹𝗲𝘁𝘁𝗲𝗿 𝘁𝗼𝗽𝗶𝗰 để xử lý retry.

Bạn đã từng để lọt bug double booking lên production chưa? Hãy chia sẻ cách bạn phát hiện ra nó nhé! 💬

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 Two guests, one room, the same night. That is the bug nobody wants to explain to a customer, and it is exactly what this 𝗛𝗼𝘁𝗲𝗹 𝗥𝗲𝘀𝗲𝗿𝘃𝗮𝘁𝗶𝗼𝗻 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 video solves. It walks through the tables, the endpoints, and the full booking flow step by step.

Here is the short version of why it works:
🗝️ 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝗰𝘆 𝗞𝗲𝘆: Fire the same booking request twice and 𝗥𝗲𝗱𝗶𝘀 remembers the key, so the user ends up with one reservation instead of two.
🏨 𝗛𝗼𝘁𝗲𝗹-𝗕𝗮𝘀𝗲𝗱 𝗦𝗵𝗮𝗿𝗱𝗶𝗻𝗴: Keeping one hotel on one shard turns a booking into a plain 𝗹𝗼𝗰𝗮𝗹 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻, so no 𝘁𝘄𝗼-𝗽𝗵𝗮𝘀𝗲 𝗰𝗼𝗺𝗺𝗶𝘁 is needed.
📅 𝗣𝗲𝗿-𝗗𝗮𝘁𝗲 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆: The 𝗿𝗼𝗼𝗺_𝗶𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆 table tracks available rooms per room type per day, and a 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗰𝗼𝗻𝘀𝘁𝗿𝗮𝗶𝗻𝘁 refuses to let the count drop below zero.
📨 𝗔𝘀𝘆𝗻𝗰 𝗪𝗵𝗲𝗿𝗲 𝗜𝘁 𝗜𝘀 𝗦𝗮𝗳𝗲: Hotel onboarding flows through 𝗞𝗮𝗳𝗸𝗮 and 𝗘𝗹𝗮𝘀𝘁𝗶𝗰𝘀𝗲𝗮𝗿𝗰𝗵 indexing accepts 𝗲𝘃𝗲𝗻𝘁𝘂𝗮𝗹 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆, because a stale search result is fine while a double booking is not.

If you build on 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁, this becomes 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗣𝗔 𝗹𝗼𝗰𝗸𝗶𝗻𝗴, 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀 for idempotency, and 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 with a 𝗱𝗲𝗮𝗱 𝗹𝗲𝘁𝘁𝗲𝗿 𝘁𝗼𝗽𝗶𝗰 for retries.

Have you ever shipped a double-booking bug? Tell us how you caught it! 💬

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

12/10/2026

[English Below]
Hello mọi người!👋 Bạn có bao giờ bấm tìm "quán ăn gần đây" và nhận kết quả chỉ trong 200ms không? Đằng sau đó là cả một bài toán thiết kế hệ thống, và hôm nay chúng ta sẽ mổ xẻ toàn bộ nó. 😄

Video này thiết kế một 𝗣𝗿𝗼𝘅𝗶𝗺𝗶𝘁𝘆 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 kiểu 𝗬𝗲𝗹𝗽: người dùng tạo địa điểm, tìm kiếm theo bán kính và viết review. Quy mô mục tiêu: 𝟱𝟬 𝗧𝗿𝗶𝗲̣̂𝘂 người dùng mỗi ngày và khoảng 𝟮.𝟲 𝗧𝗕 dữ liệu mới mỗi năm.

Dưới đây là những điểm làm nên thiết kế này:
🗺️ 𝗚𝗲𝗼𝗵𝗮𝘀𝗵 𝘁𝗵𝗮𝘆 𝗰𝗵𝗼 𝗧𝗼̣𝗮 𝐝𝗼̣̂ 𝗧𝗵𝗼̂: Latitude và longitude được mã hóa thành một chuỗi ngắn, nên "gần tôi" trở thành phép so khớp 𝘀𝘁𝗿𝗶𝗻𝗴 𝗽𝗿𝗲𝗳𝗶𝘅 đơn giản thay vì quét toàn bộ bảng.
🤝 𝗛𝗮𝗶 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲, 𝗠𝗼̣̂𝘁 𝗡𝗵𝗶𝗲̣̂𝗺 𝘃𝘂̣: 𝗘𝗹𝗮𝘀𝘁𝗶𝗰𝘀𝗲𝗮𝗿𝗰𝗵 lọc ứng viên theo keyword và 𝗯𝗼𝘂𝗻𝗱𝗶𝗻𝗴 𝗯𝗼𝘅, sau đó 𝗣𝗼𝘀𝘁𝗚𝗜𝗦 tính khoảng cách chính xác để xác nhận ai thực sự nằm trong bán kính.
⚡ 𝗖𝗮𝗰𝗵𝗲 𝗻𝗵𝘂̛̃𝗻𝗴 𝗴𝗶̀ 𝗹𝗮̣̆𝗽 𝗹𝗮̣𝗶: Các query phổ biến và điểm rating trung bình được lưu trong 𝗥𝗲𝗱𝗶𝘀, vì cùng một câu "pizza ở Quận 1" chạy hàng nghìn lần mỗi giờ.
🛡️ 𝗥𝗮𝘁𝗲 𝗟𝗶𝗺𝗶𝘁𝗶𝗻𝗴 𝗻𝗴𝗮𝘆 𝗰𝘂̛̉𝗮 𝗻𝗴𝗼̃: Áp dụng 𝘁𝗼𝗸𝗲𝗻 𝗯𝘂𝗰𝗸𝗲𝘁 hoặc 𝘀𝗹𝗶𝗱𝗶𝗻𝗴 𝘄𝗶𝗻𝗱𝗼𝘄 ở 𝘄𝗿𝗶𝘁𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 để một client bất thường không làm sập cả hệ thống.

Nếu bạn làm việc với 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁, đây là những thứ rất quen thuộc: 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗣𝗔 kết hợp 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 𝗦𝗽𝗮𝘁𝗶𝗮𝗹 cho PostGIS, 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀 cho cache, và 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 cho phần metadata bất đồng bộ.

Nếu đi phỏng vấn, bạn sẽ xử lý phần nào trước? Hãy chia sẻ câu trả lời của bạn dưới phần bình luận nhé! 💬

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 Ever tapped "restaurants near me" and got an answer in 200ms? Somebody spent a lot of design effort on that, and we get to see the whole thing today. 😄

This video designs a 𝗣𝗿𝗼𝘅𝗶𝗺𝗶𝘁𝘆 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 like 𝗬𝗲𝗹𝗽: users create attractions, search them within a radius, and leave reviews. Scale target: 𝟱𝟬𝗠 daily users and ~𝟮.𝟲 𝗧𝗕 of new data per year.

Here is what makes it click:
🗺️ 𝗚𝗲𝗼𝗵𝗮𝘀𝗵 𝗼𝘃𝗲𝗿 𝗥𝗮𝘄 𝗖𝗼𝗼𝗿𝗱𝘀: Latitude and longitude become one short string, so "near me" turns into a plain 𝘀𝘁𝗿𝗶𝗻𝗴 𝗽𝗿𝗲𝗳𝗶𝘅 lookup instead of scanning every row.
🤝 𝗧𝘄𝗼 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲𝘀, 𝗢𝗻𝗲 𝗝𝗼𝗯: 𝗘𝗹𝗮𝘀𝘁𝗶𝗰𝘀𝗲𝗮𝗿𝗰𝗵 narrows candidates by keyword and 𝗯𝗼𝘂𝗻𝗱𝗶𝗻𝗴 𝗯𝗼𝘅, then 𝗣𝗼𝘀𝘁𝗚𝗜𝗦 confirms who is truly inside the radius.
⚡ 𝗖𝗮𝗰𝗵𝗲 𝘁𝗵𝗲 𝗢𝗯𝘃𝗶𝗼𝘂𝘀 𝗦𝘁𝘂𝗳𝗳: Popular queries and average ratings sit in 𝗥𝗲𝗱𝗶𝘀, because the same "pizza in District 1" query runs thousands of times an hour.
🛡️ 𝗥𝗮𝘁𝗲 𝗟𝗶𝗺𝗶𝘁𝗶𝗻𝗴 𝗨𝗽 𝗙𝗿𝗼𝗻𝘁: A 𝘁𝗼𝗸𝗲𝗻 𝗯𝘂𝗰𝗸𝗲𝘁 or 𝘀𝗹𝗶𝗱𝗶𝗻𝗴 𝘄𝗶𝗻𝗱𝗼𝘄 on the 𝘄𝗿𝗶𝘁𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 keeps one noisy client from taking everyone down.

If you build with 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁, this is a normal Tuesday: 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗣𝗔 with 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 𝗦𝗽𝗮𝘁𝗶𝗮𝗹 for PostGIS, 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀 for the cache, and 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 for async metadata.

Which part would you tackle first in an interview? Drop your answer below! 💬

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

11/10/2026

[English Below]
Hello mọi người!👋 Agent của bạn gửi một cú click, và trang web không phản hồi gì cả. Không lỗi, không exception, chỉ im lặng. Bài talk "𝗧𝗵𝗲 𝗗𝗮𝗿𝗸 𝗔𝗿𝘁𝘀 𝗼𝗳 𝗪𝗲𝗯 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻" của 𝗖𝗼𝗿𝗲𝘆 𝗚𝗮𝗹𝗹𝗼𝗻 giải thích nguyên nhân và đưa ra một phương pháp có thể lặp lại để xử lý vấn đề này.

Ý tưởng chính nằm gọn trong một câu: một browser được điều khiển qua 𝗖𝗵𝗿𝗼𝗺𝗲 𝗗𝗲𝘃𝗧𝗼𝗼𝗹𝘀 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹 (𝗖𝗗𝗣) gửi mọi click và keystroke qua đúng đường đi mà chuột của bạn vẫn dùng. Chrome đánh dấu các event đó là 𝘁𝗿𝘂𝘀𝘁𝗲𝗱; còn một synthetic JavaScript click sẽ bị đánh dấu 𝘂𝗻𝘁𝗿𝘂𝘀𝘁𝗲𝗱 và trang web âm thầm bỏ qua nó.

Dưới đây là những điểm làm nên hiệu quả của phương pháp này:
⚙️ 𝗖𝗟𝗜 𝗢𝘃𝗲𝗿 𝗠𝗖𝗣: Cả hai đều đạt tỉ lệ thành công khoảng 83%, nhưng 𝗖𝗟𝗜 hoàn thành trong 7 turns và dưới một phút, trong khi 𝗠𝗖𝗣 cần 71 round trips và 8 phút, với token cost cao hơn tới 75 lần.
🧭 𝗗𝗶𝗴𝗶𝘁𝗮𝗹 𝗦𝗲𝗻𝘀𝗲𝘀: Bạn chỉ cần một phần nhỏ trong 57 domains của 𝗖𝗗𝗣 — đọc 𝗗𝗢𝗠 và 𝗔𝗰𝗰𝗲𝘀𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗧𝗿𝗲𝗲, chụp screenshots, theo dõi network traffic, rồi mới thao tác.
🔁 𝗦𝗲𝗻𝘀𝗲–𝗔𝗰𝘁–𝗩𝗲𝗿𝗶𝗳𝘆: Thực hiện một hành động, sau đó xác nhận kết quả qua một kênh khác với kênh bạn vừa dùng để thao tác.
🪜 𝗧𝗵𝗲 𝗧𝗵𝗿𝗲𝗲-𝗥𝘂𝗻𝗴 𝗟𝗮𝗱𝗱𝗲𝗿: Bắt đầu bằng synthetic click, nâng lên trusted 𝗖𝗗𝗣 𝗜𝗻𝗽𝘂𝘁 events, và chỉ dùng đến mouse paths giống người thật kèm vision khi trang web bắt buộc bạn phải làm vậy.

Đối với các team 𝗝𝗮𝘃𝗮 và 𝗦𝗽𝗿𝗶𝗻𝗴, điều này đặc biệt hữu ích với các internal portals và SaaS consoles, nơi official API đòi hỏi app registration và phê duyệt từ admin mà bạn gần như không bao giờ xin được. Web UI khi đó trở thành một API không cần xin quyền để 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁 job của bạn chạy theo lịch.

Bạn đã từng tự động hóa một hệ thống không có API nào dùng được chưa? Hãy chia sẻ cách bạn làm ở phần bình luận nhé! 💬

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 Your agent fires a click, and the page does nothing. No error, no failure, just silence. 𝗖𝗼𝗿𝗲𝘆 𝗚𝗮𝗹𝗹𝗼𝗻'𝘀 talk "𝗧𝗵𝗲 𝗗𝗮𝗿𝗸 𝗔𝗿𝘁𝘀 𝗼𝗳 𝗪𝗲𝗯 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻" explains why that happens and gives a repeatable method to fix it.

The premise sits on one line: a browser driven through the 𝗖𝗵𝗿𝗼𝗺𝗲 𝗗𝗲𝘃𝗧𝗼𝗼𝗹𝘀 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹 (𝗖𝗗𝗣) sends every click and keystroke down the same path your own mouse uses. Chrome stamps those events 𝘁𝗿𝘂𝘀𝘁𝗲𝗱; a synthetic JavaScript click gets stamped 𝘂𝗻𝘁𝗿𝘂𝘀𝘁𝗲𝗱 and pages quietly drop it.

Here is what makes the method work:
⚙️ 𝗖𝗟𝗜 𝗢𝘃𝗲𝗿 𝗠𝗖𝗣: Both hit roughly 83% task success, but the 𝗖𝗟𝗜 finished in 7 turns and under a minute where 𝗠𝗖𝗣 took 71 round trips and 8 minutes, at up to 75x lower token cost.
🧭 𝗗𝗶𝗴𝗶𝘁𝗮𝗹 𝗦𝗲𝗻𝘀𝗲𝘀: You need a small subset of 𝗖𝗗𝗣'𝘀 57 domains — read the 𝗗𝗢𝗠 and 𝗔𝗰𝗰𝗲𝘀𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗧𝗿𝗲𝗲, capture screenshots, watch network traffic, then operate.
🔁 𝗦𝗲𝗻𝘀𝗲–𝗔𝗰𝘁–𝗩𝗲𝗿𝗶𝗳𝘆: Make one move, then confirm it landed through a different channel than the one you acted on.
🪜 𝗧𝗵𝗲 𝗧𝗵𝗿𝗲𝗲-𝗥𝘂𝗻𝗴 𝗟𝗮𝗱𝗱𝗲𝗿: Start with a synthetic click, climb to trusted 𝗖𝗗𝗣 𝗜𝗻𝗽𝘂𝘁 events, and reach human-like mouse paths with vision only when the page forces you.

For 𝗝𝗮𝘃𝗮 and 𝗦𝗽𝗿𝗶𝗻𝗴 teams, this matters most on internal portals and SaaS consoles where the official API needs an app registration and admin approval you will never get. The web UI becomes a permissionless API your 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁 job can drive on a schedule.

Have you automated a system that had no usable API? Tell us how in the comments! 💬

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

10/10/2026

[English Below]
Hello mọi người!👋 Nếu team của bạn vừa migrate từ 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 sang 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 và có ai đó hỏi "lazy loading đâu rồi?", bài talk này chính là dành cho bạn.

Tại Spring I/O 2026, 𝗠𝗶𝗸𝗵𝗮𝗶𝗹 𝗣𝗼𝗹𝗶𝘃𝗮𝗸𝗵𝗮 trình bày "𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 - 𝗧𝗮𝗺𝗶𝗻𝗴 𝘁𝗵𝗲 𝗕𝗲𝗮𝘀𝘁", đi sâu vào bản chất thực sự của 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 và vị trí của nó trong kiến trúc hệ thống. Anh cho rằng 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲/𝗝𝗣𝗔 được xây dựng cho độ phức tạp của thời monolith, còn 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 nhắm vào một thế giới khác: microservices với schema nhỏ và có ranh giới rõ ràng.

Dưới đây là lý do sự khác biệt này quan trọng:
🌳 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗲𝘀 𝗻𝗵𝘂̛ 𝗖𝗮̂𝘆: Mỗi aggregate được model như một cây, chỉ có quan hệ one-to-many hoặc one-to-one, không có many-to-many, đây là thiết kế có chủ đích.
🚫 𝗞𝗵𝗼̂𝗻𝗴 𝗖𝗼́ 𝗟𝗮𝘇𝘆 𝗟𝗼𝗮𝗱𝗶𝗻𝗴: Không có phép màu fetch graph nào cả; mọi aggregate được load toàn bộ, buộc bạn phải giữ aggregate thực sự nhỏ gọn.
🧩 𝗣𝗵𝘂̀ 𝗛𝗼̛̣𝗽 𝘃𝗼̛́𝗶 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀: Với mỗi microservice có một database riêng, schema vẫn giữ nhỏ nên bạn không cần đến bộ tính năng cồng kềnh của 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲.
🔒 𝗧𝗶́𝗻𝗵 𝗡𝗵𝗮̂́𝘁 𝗾𝘂𝗮́𝗻 𝗖𝗵𝗮̣̆𝘁 𝗰𝗵𝗲̃: Mỗi lệnh insert và read đều nằm trong một transaction chỉ chạm vào aggregate root và các con của nó, giữ cho invariant luôn sạch.

Đối với các 𝗝𝗮𝘃𝗮/𝗦𝗽𝗿𝗶𝗻𝗴 developers đang thiết kế service theo 𝗗𝗼𝗺𝗮𝗶𝗻-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘀𝗶𝗴𝗻, bài talk này định nghĩa lại 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 không phải là "JPA bản rút gọn," mà là công cụ đúng đắn khi domain của bạn đã được chia thành các bounded context.

Team của bạn đang dùng gì để lưu trữ dữ liệu trong microservices — 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 hay vẫn là 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲?

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 If your team just migrated from 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 to 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 and someone asked "where's my lazy loading?", this talk is for you.

At Spring I/O 2026, 𝗠𝗶𝗸𝗵𝗮𝗶𝗹 𝗣𝗼𝗹𝗶𝘃𝗮𝗸𝗵𝗮 delivered "𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 - 𝗧𝗮𝗺𝗶𝗻𝗴 𝘁𝗵𝗲 𝗕𝗲𝗮𝘀𝘁", a deep dive into what 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 actually is, and where it belongs in your architecture. He argues 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲/𝗝𝗣𝗔 was built for monolith-era complexity, while 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 targets a different world: microservices with small, bounded schemas.

Here is why this distinction matters:
🌳 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗲𝘀 𝗮𝘀 𝗧𝗿𝗲𝗲𝘀: Each aggregate models as a tree with only one-to-many or one-to-one relations, no many-to-many, by design.
🚫 𝗡𝗼 𝗟𝗮𝘇𝘆 𝗟𝗼𝗮𝗱𝗶𝗻𝗴: There's no fetch graph magic; every aggregate loads in full, forcing you to keep aggregates genuinely small.
🧩 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗙𝗶𝘁: With one database per microservice, your schema stays small, so you don't need 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲's heavyweight feature set.
🔒 𝗦𝘁𝗿𝗶𝗰𝘁 𝗖𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆: Every insert and read wraps in a transaction touching the aggregate root and its children only, keeping invariants clean.

For 𝗝𝗮𝘃𝗮/𝗦𝗽𝗿𝗶𝗻𝗴 developers designing services under 𝗗𝗼𝗺𝗮𝗶𝗻-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘀𝗶𝗴𝗻, this talk reframes 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 not as "JPA-lite," but as the correct tool once your domain splits into bounded contexts.

What's your team using for persistence in microservices — 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗝𝗗𝗕𝗖 or still 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲?

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

09/10/2026

[English Below]
Hello mọi người!👋 Một 𝗹𝗲𝗮𝗱𝗲𝗿𝗯𝗼𝗮𝗿𝗱 nhìn qua thì rất đơn giản, cho đến khi 10 triệu người dùng hàng ngày đẩy 50.000 lượt cập nhật điểm mỗi giây. Video 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻 này xây dựng một 𝗧𝗼𝗽-𝗞 𝗟𝗲𝗮𝗱𝗲𝗿𝗯𝗼𝗮𝗿𝗱 trả về top 100 toàn cục trong dưới 20 ms ở mức 𝗣𝟵𝟵, và giải thích lý do đằng sau từng lựa chọn component.

Dưới đây là những điểm nổi bật của thiết kế này:
🧮 𝗥𝗲𝗱𝗶𝘀 𝗦𝗼𝗿𝘁𝗲𝗱 𝗦𝗲𝘁𝘀: Một 𝗭𝗦𝗘𝗧 kết hợp hash map để tra cứu điểm số với độ phức tạp 𝗢(𝟭) và skip list cho các truy vấn rank và range với độ phức tạp 𝗢(𝗹𝗼𝗴 𝗡).
🛡️ 𝗪𝗿𝗶𝘁𝗲-𝗕𝗮𝗰𝗸 𝗕𝘂𝗳𝗳𝗲𝗿 𝘃𝗮̀ 𝗞𝗮𝗳𝗸𝗮: Write service gộp các lượt tăng điểm trong một khoảng thời gian ngắn, sau đó 𝗞𝗮𝗳𝗸𝗮 làm mượt các đợt traffic tăng đột biến để Redis nhận tải ổn định.
🔑 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝗰𝘆 𝗞𝗲𝘆𝘀: Mỗi request mang một ID duy nhất, nên việc client retry sau khi server crash sẽ không bao giờ cộng trùng điểm hai lần.
🧩 𝗛𝗮𝘀𝗵 𝗦𝗵𝗮𝗿𝗱𝗶𝗻𝗴 𝘃𝗮̀ 𝗦𝗰𝗮𝘁𝘁𝗲𝗿-𝗚𝗮𝘁𝗵𝗲𝗿: Shard theo hash của user ID, lấy top K từ mọi shard, merge trong memory, rồi cache kết quả với 𝗧𝗧𝗟 ngắn.

Đối với các 𝗝𝗮𝘃𝗮/𝗦𝗽𝗿𝗶𝗻𝗴 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀, thiết kế này ánh xạ trực tiếp sang 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀 𝗭𝗦𝗲𝘁𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 cho hot path, 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 listeners cho phần ingestion, và một job @𝗦𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗱 để build lại các bảng xếp hạng theo tuần.

Bạn sẽ chọn chiến lược sharding nào cho leaderboard của mình, fixed range hay hash partitioning? Hãy chia sẻ bên dưới nhé! 💬

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 A leaderboard looks trivial until 10 million daily active users push 50,000 score updates per second. This 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻 walkthrough builds a 𝗧𝗼𝗽-𝗞 𝗟𝗲𝗮𝗱𝗲𝗿𝗯𝗼𝗮𝗿𝗱 that returns the global top 100 in under 20 ms at 𝗣𝟵𝟵, and it justifies every component choice.

Here is why the design holds up:
🧮 𝗥𝗲𝗱𝗶𝘀 𝗦𝗼𝗿𝘁𝗲𝗱 𝗦𝗲𝘁𝘀: A 𝗭𝗦𝗘𝗧 combines a hash map for 𝗢(𝟭) score lookups with a skip list for 𝗢(𝗹𝗼𝗴 𝗡) rank and range queries.
🛡️ 𝗪𝗿𝗶𝘁𝗲-𝗕𝗮𝗰𝗸 𝗕𝘂𝗳𝗳𝗲𝗿 𝗮𝗻𝗱 𝗞𝗮𝗳𝗸𝗮: The write service merges increments over a short window, then 𝗞𝗮𝗳𝗸𝗮 smooths traffic spikes so Redis takes a steady load.
🔑 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝗰𝘆 𝗞𝗲𝘆𝘀: Every request carries a unique ID, so a client retry after a server crash never counts the same score twice.
🧩 𝗛𝗮𝘀𝗵 𝗦𝗵𝗮𝗿𝗱𝗶𝗻𝗴 𝗮𝗻𝗱 𝗦𝗰𝗮𝘁𝘁𝗲𝗿-𝗚𝗮𝘁𝗵𝗲𝗿: Shard by user ID hash, pull the top K from every shard, merge in memory, then cache the result with a short 𝗧𝗧𝗟.

For 𝗝𝗮𝘃𝗮/𝗦𝗽𝗿𝗶𝗻𝗴 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀, this maps onto 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀 𝗭𝗦𝗲𝘁𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 for the hot path, 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 listeners for ingestion, and a @𝗦𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗱 aggregation job that rebuilds rolling weekly views.

Which sharding strategy would you pick for your leaderboard, fixed range or hash partitioning? Tell us below! 💬

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

08/10/2026

[English Below]
Hello mọi người!👋 Mọi distributed system sớm muộn cũng sinh ra những message không chịu xử lý được. Câu hỏi là: chuyện gì xảy ra với chúng sau đó?

Tại Spring I/O 2026, Joris Kuipers đã trình bày 𝗙𝗮𝗹𝗹𝗼𝘂𝘁: 𝗗𝗲𝗮𝗱 𝗟𝗲𝘁𝘁𝗲𝗿 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗔𝘁 𝗦𝗰𝗮𝗹𝗲, đúc kết từ kinh nghiệm vận hành một integration platform dùng AWS SQS với hơn 50 queues và khoảng 20 triệu messages mỗi tháng. Luận điểm chính của anh: hầu hết hệ thống biết cách đẩy một message lỗi ra khỏi main queue, nhưng gần như không ai biết phải làm gì với nó sau đó — biến dead letter queue (DLQ) thành cái anh gọi là "nghĩa địa".

Dưới đây là lý do bài nói này đáng chú ý với các backend engineer:
🔍 𝗣𝗵𝗮̂𝗻 𝗹𝗼𝗮̣𝗶 𝗹𝗼̂̃𝗶: Khoảng 95% message bị dead-letter là do lỗi tạm thời (transient error), không phải bug, nên retry logic — chứ không phải sửa code — giải quyết được phần lớn.
🧵 𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝗧𝗿𝗮𝗰𝗶𝗻𝗴: Gắn W3C trace ID qua Micrometer giúp một tool quản lý liên kết trực tiếp mỗi message lỗi với log tương ứng, vì bản thân payload hiếm khi giải thích được nguyên nhân lỗi.
🔁 𝗥𝗲𝘁𝗿𝘆 𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴: Một custom dequeue counter giữ lại số lần message đã được retry, thông tin mà AWS xóa mất khi copy message quay lại source queue.
♻️ 𝗧𝘂̛̣ đ𝗼̣̂𝗻𝗴 𝗵𝗼́𝗮 𝘀𝗲𝗹𝗳-𝗵𝗲𝗮𝗹𝗶𝗻𝗴: Auto-requeue theo lịch cho từng queue, kết hợp auto-purge trên môi trường non-production, loại bỏ phần lớn việc xử lý thủ công.

Đối với các team Java và Spring vận hành messaging ở quy mô thực tế, đây là một blueprint vững chắc để kết hợp observability dựa trên Micrometer với SQS, JMS hoặc RabbitMQ, ngăn DLQ trở thành nơi chôn vùi lỗi trong im lặng.

Team của bạn hiện đang xử lý dead letter queue như thế nào?

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 Every distributed system eventually produces messages that refuse to process. The question is: what happens to them after that?

At Spring I/O 2026, Joris Kuipers presented 𝗙𝗮𝗹𝗹𝗼𝘂𝘁: 𝗗𝗲𝗮𝗱 𝗟𝗲𝘁𝘁𝗲𝗿 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗔𝘁 𝗦𝗰𝗮𝗹𝗲, drawn from running an AWS SQS-based integration platform with 50+ queues and roughly 20 million messages a month. His core argument: most systems know how to move a failed message off the main queue, but almost none tell you what to do with it afterward — turning the dead letter queue (DLQ) into what he calls a "graveyard."

Here is why this talk stands out for backend engineers:
🔍 𝗙𝗮𝗶𝗹𝘂𝗿𝗲 𝗖𝗹𝗮𝘀𝘀𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻: Roughly 95% of dead-lettered messages are transient errors, not bugs, so retry logic — not code fixes — resolves most of them.
🧵 𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝗧𝗿𝗮𝗰𝗶𝗻𝗴: Embedding W3C trace IDs via Micrometer lets a management tool link every failed message directly to its logs, since the payload alone rarely explains the failure.
🔁 𝗥𝗲𝘁𝗿𝘆 𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴: A custom dequeue counter preserves how many times a message has been retried, information AWS discards when it copies a message back to the source queue.
♻️ 𝗦𝗲𝗹𝗳-𝗛𝗲𝗮𝗹𝗶𝗻𝗴 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻: Scheduled auto-requeue per queue, combined with auto-purge on non-production environments, removes most manual firefighting.

For Java and Spring teams running messaging at any real scale, this is a strong blueprint for pairing Micrometer-based observability with SQS, JMS, or RabbitMQ to stop DLQs from becoming silent failure sinks.

What's your team's current strategy for dead letter queues?

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

07/10/2026

[English Below]
Hello mọi người!👋 Bạn có bao giờ thắc mắc tại sao TikTok gần như không bao giờ bị buffer, ngay cả khi mạng 4G yếu? Không có phép màu nào ở đây cả — một background thread đã âm thầm tải trước 2 giây đầu tiên của ba video kế tiếp trước khi bạn kịp vuốt màn hình.

Bài phân tích 19 phút này từ 𝗧𝗲𝗰𝗵𝗣𝗿𝗲𝗽 sẽ thiết kế toàn bộ hệ thống: quá trình upload, feed cá nhân hóa vô tận, và learning loop giúp huấn luyện lại thuật toán ranking theo thời gian thực.

Dưới đây là những phần đáng chú ý nhất:
📥 𝗣𝗿𝗲-𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗽𝗹𝗼𝗮𝗱𝘀: Client đẩy file MP4 trực tiếp lên 𝗦𝟯 qua 𝗽𝗿𝗲-𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗥𝗟, nhờ vậy backend của bạn không phải xử lý dù chỉ một byte video nào.
🔁 𝗧𝗲𝗺𝗽𝗼𝗿𝗮𝗹 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀: Các bước moderation, audio extraction và chunking chạy chung trong một 𝗗𝗔𝗚. Khi một 𝗚𝗣𝗨 node chết giữa chừng, workflow sẽ tiếp tục đúng tại điểm đã dừng.
📲 𝗖𝗹𝗶𝗲𝗻𝘁-𝗦𝗶𝗱𝗲 𝗣𝗿𝗲𝗳𝗲𝘁𝗰𝗵𝗶𝗻𝗴: App tải sẵn vài video kế tiếp vào RAM của thiết bị trong lúc bạn đang xem video hiện tại, nên mỗi lần vuốt gần như không tốn thời gian chờ network.
💾 𝗥𝗲𝗱𝗶𝘀 𝗧𝗿𝘂̛𝗼̛́𝗰, 𝗖𝗮𝘀𝘀𝗮𝗻𝗱𝗿𝗮 𝗦𝗮𝘂: Lượt like được cộng dồn trong memory trước, sau đó một cron job mới ghi tổng số xuống database — giúp 𝗖𝗮𝘀𝘀𝗮𝗻𝗱𝗿𝗮 tránh được 100.000 lượt ghi không cần thiết.

Nếu bạn đang xây dựng các service với 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁, mô hình này rất quen thuộc: một 𝗞𝗮𝗳𝗸𝗮 𝗹𝗶𝘀𝘁𝗲𝗻𝗲𝗿 tách rời quá trình upload khỏi phần xử lý, và 𝗥𝗲𝗱𝗶𝘀 hấp thụ các đợt ghi tăng đột biến trước khi chúng dội thẳng vào primary database.

Bạn đã dùng 𝗽𝗿𝗲𝗳𝗲𝘁𝗰𝗵𝗶𝗻𝗴 hay 𝘄𝗿𝗶𝘁𝗲 𝗰𝗼𝗮𝗹𝗲𝘀𝗰𝗶𝗻𝗴 trong production chưa? Chia sẻ trải nghiệm của bạn nhé! 💬

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 Ever wondered why TikTok never buffers, even on a weak 4G connection? No magic involved — a background thread quietly grabs the first 2 seconds of your next three videos before you swipe.

This 19-minute walkthrough from 𝗧𝗲𝗰𝗵𝗣𝗿𝗲𝗽 designs the whole thing: uploads, an infinite personalized feed, and a learning loop that retrains ranking in real time.

Here are the parts that stuck with me:
📥 𝗣𝗿𝗲-𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗽𝗹𝗼𝗮𝗱𝘀: Clients push MP4 files straight to 𝗦𝟯 using a 𝗽𝗿𝗲-𝘀𝗶𝗴𝗻𝗲𝗱 𝗨𝗥𝗟, so your backend never handles a single video byte.
🔁 𝗧𝗲𝗺𝗽𝗼𝗿𝗮𝗹 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀: Moderation, audio extraction, and chunking run as one 𝗗𝗔𝗚, and when a 𝗚𝗣𝗨 node dies mid-job the workflow resumes exactly where it stopped.
📲 𝗖𝗹𝗶𝗲𝗻𝘁-𝗦𝗶𝗱𝗲 𝗣𝗿𝗲𝗳𝗲𝘁𝗰𝗵𝗶𝗻𝗴: The app pulls the next few videos into local RAM while you watch the current one, so a swipe costs almost zero network wait.
💾 𝗥𝗲𝗱𝗶𝘀 𝗕𝗲𝗳𝗼𝗿𝗲 𝗖𝗮𝘀𝘀𝗮𝗻𝗱𝗿𝗮: Like counts pile up in memory first, then a cron job flushes the total — saving 𝗖𝗮𝘀𝘀𝗮𝗻𝗱𝗿𝗮 from 100,000 writes it never needed.

If you build 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁 services, you already know this shape: a 𝗞𝗮𝗳𝗸𝗮 𝗹𝗶𝘀𝘁𝗲𝗻𝗲𝗿 decoupling upload from processing, and 𝗥𝗲𝗱𝗶𝘀 absorbing write spikes before they hit your primary database.

Have you used 𝗽𝗿𝗲𝗳𝗲𝘁𝗰𝗵𝗶𝗻𝗴 or 𝘄𝗿𝗶𝘁𝗲 𝗰𝗼𝗮𝗹𝗲𝘀𝗰𝗶𝗻𝗴 in production? Tell us how it went! 💬

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

06/10/2026

[English Below]
Hello mọi người!👋 Bạn có từng nghĩ Java "tốn" RAM hơn C++ hay Rust? Một buổi chia sẻ chuyên sâu về JVM memory management vừa đưa ra lập luận ngược lại hoàn toàn.

Trong session "𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗼𝗳 𝗠𝗲𝗺𝗼𝗿𝘆 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗶𝗻 𝗝𝗮𝘃𝗮", diễn giả phân tích lý do mọi 𝗴𝗮𝗿𝗯𝗮𝗴𝗲 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗼𝗿 trong JDK đều là 𝗺𝗼𝘃𝗶𝗻𝗴, 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗼𝗿 — và tại sao thiết kế này chủ động đánh đổi RAM lấy CPU, khác hẳn model malloc/free hay reference-counting của C, Rust hay Swift.

Dưới đây là những điểm nổi bật:
🧵 𝗞𝗵𝗼̂𝗻𝗴 𝗠𝗮𝗹𝗹𝗼𝗰, 𝗞𝗵𝗼̂𝗻𝗴 𝗙𝗿𝗲𝗲: JVM không bao giờ free từng object riêng lẻ — nó bump-allocate và compact các object còn sống, loại bỏ hoàn toàn chi phí deallocation trên từng object.
🧬 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗛𝘆𝗽𝗼𝘁𝗵𝗲𝘀𝗶𝘀: Vì hầu hết object chết sớm, các đợt thu gom ở young generation luôn rẻ và việc promote lên old generation rất hiếm, khiến chi phí GC mang tính cộng dồn chứ không nhân lên.
💰 𝗥𝗔𝗠 𝗩𝗼̂́𝗻 𝗔̆𝟯 𝗧𝗿𝗮̉ 𝗧𝗶𝗲̂̀𝗻: Các cloud instance thường đi kèm hơn 1GB RAM mỗi core dù bạn dùng hết hay không, nên dùng RAM đó để giảm tải CPU gần như miễn phí.
📊 𝗤𝘂𝗮𝗻 𝗦𝗮́𝘁 𝗠𝗼̛́𝗶 𝗧𝗿𝗼𝗻𝗴 𝗝𝗗𝗞 𝟮𝟲: JMX giờ đây hiển thị chính xác chi phí CPU của garbage collection, và tính năng dynamic heap sizing tự động cho ZGC sắp ra mắt.

Đối với các team chạy Spring Boot trên Kubernetes, đây là lúc thay đổi cách suy nghĩ về heap sizing: đừng cố giảm thiểu -Xmx, hãy set nó khớp với tier RAM bạn đã trả tiền.

Team của bạn đang set -Xmx trong production như thế nào?
(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 Ever assumed Java "wastes" RAM compared to C++ or Rust? A recent deep-dive talk on JVM memory management makes a rigorous case that this assumption is backwards.

The session, 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗼𝗳 𝗠𝗲𝗺𝗼𝗿𝘆 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗶𝗻 𝗝𝗮𝘃𝗮, breaks down why every 𝗴𝗮𝗿𝗯𝗮𝗴𝗲 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗼𝗿 in the JDK is a 𝗺𝗼𝘃𝗶𝗻𝗴, 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗼𝗿 — and why that design deliberately trades RAM for CPU efficiency, unlike the malloc/free or reference-counting models used in C, Rust, or Swift.

Here is why this framing matters:
🧵 𝗡𝗼 𝗠𝗮𝗹𝗹𝗼𝗰, 𝗡𝗼 𝗙𝗿𝗲𝗲: The JVM never frees individual objects — it bump-allocates and compacts survivors, eliminating per-object deallocation cost entirely.
🧬 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗛𝘆𝗽𝗼𝘁𝗵𝗲𝘀𝗶𝘀: Since most objects die young, young-generation collections stay cheap and old-generation promotion stays rare, making GC cost additive rather than multiplicative.
💰 𝗥𝗔𝗠 𝗶𝘀 𝗔𝗹𝗿𝗲𝗮𝗱𝘆 𝗣𝗮𝗶𝗱 𝗙𝗼𝗿: Cloud instances bundle roughly 1GB+ of RAM per core regardless of usage, so spending that RAM to cut CPU load is close to free.
📊 𝗡𝗲𝘄 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝗻 𝗝𝗗𝗞 𝟮𝟲: JMX now exposes the exact CPU cost of garbage collection, with automatic dynamic heap sizing for ZGC coming next.

For teams running Spring Boot services on Kubernetes, this reframes heap sizing: stop minimizing -Xmx and start matching it to the RAM tier you already pay for.

What is your current -Xmx strategy in production?
(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝗼𝗻 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

05/10/2026

[English Below]
Hello mọi người!👋 Chắc hẳn ai trong chúng ta cũng từng F5 trang bán vé đúng 10:00 sáng và nhìn nó "sập". Hóa ra cách khắc phục không nằm ở việc nâng cấp server mạnh hơn, mà là 𝗹𝗼𝗰𝗸𝗶𝗻𝗴 thông minh hơn.

Video của 𝗧𝗲𝗰𝗵𝗣𝗿𝗲𝗽 sẽ thiết kế một hệ thống đặt vé kiểu 𝗧𝗶𝗰𝗸𝗲𝘁𝗺𝗮𝘀𝘁𝗲𝗿 từ requirements đến toàn bộ request flow, và phần deep dive mới thực sự là điểm nhấn.

Dưới đây là những điểm đáng chú ý nhất:
🛡️ 𝗥𝗲𝗱𝗶𝘀 𝗕𝗮̉𝗼 𝗩𝗲̣̂ 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲: Một key 𝗦𝗘𝗧 𝗡𝗫 chặn ngay 9.999 request thua cuộc, nên chỉ những ứng viên thực sự mới chạm tới transaction 𝗣𝗼𝘀𝘁𝗴𝗿𝗲𝗦𝗤𝗟 của bạn.
✅ 𝗦𝗤𝗟 𝗕𝗮̉𝗼 𝗩𝗲̣̂ 𝗧𝗶́𝗻𝗵 Đ𝘂́𝗻𝗴 Đ𝗮̆́𝗻: 𝗦𝗘𝗟𝗘𝗖𝗧 ... 𝗙𝗢𝗥 𝗨𝗣𝗗𝗔𝗧𝗘 buộc từng row phải xếp hàng chờ, nên hai user không bao giờ cùng nhận được thông báo "đặt vé thành công".
🎟️ 𝗛𝗮̀𝗻𝗴 Đ𝗼̛̣𝗶 Đ𝘂́𝗻𝗴 𝗡𝗴𝗵𝗶̃𝗮: 𝗞𝗮𝗳𝗸𝗮 giữ nguyên thứ tự đến, còn client chỉ poll một con số "đang phục vụ tới lượt X" được cache trên 𝗖𝗗𝗡 mỗi 30 giây thay vì dội bom API.
🧹 𝗚𝗵𝗲̂́ 𝗧𝘂̛̣ Đ𝗼̣̂𝗻𝗴 Đ𝘂̛𝗼̛̣𝗰 𝗚𝗶𝗮̉𝗶 𝗣𝗵𝗼́𝗻𝗴: Một task trong 𝗱𝗲𝗹𝗮𝘆 𝗾𝘂𝗲𝘂𝗲 sau 10 phút sẽ kiểm tra các booking chưa thanh toán, lật bit trong 𝗥𝗲𝗱𝗶𝘀 về 0, và ghế lại sáng xanh.

Nếu bạn xây dựng các service 𝗝𝗮𝘃𝗮/𝗦𝗽𝗿𝗶𝗻𝗴, đây chính là cẩm nang cho flash sale, giữ chỗ và quản lý inventory: @𝗟𝗼𝗰𝗸(𝗣𝗘𝗦𝗦𝗜𝗠𝗜𝗦𝗧𝗜𝗖_𝗪𝗥𝗜𝗧𝗘), 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀 và 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 lo phần lớn công việc cho bạn.

Bạn đã từng đưa một 𝘄𝗮𝗶𝘁𝗶𝗻𝗴 𝗿𝗼𝗼𝗺 lên production chưa? Kể xem thứ gì hỏng đầu tiên nhé 😄

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 We have all refreshed a ticket page at 10:00 AM sharp and watched it die. Turns out the fix is not a bigger server — it is smarter 𝗹𝗼𝗰𝗸𝗶𝗻𝗴.

This 𝗧𝗲𝗰𝗵𝗣𝗿𝗲𝗽 walkthrough designs a 𝗧𝗶𝗰𝗸𝗲𝘁𝗺𝗮𝘀𝘁𝗲𝗿-𝗹𝗶𝗸𝗲 𝗯𝗼𝗼𝗸𝗶𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺 from requirements to the full request flow, and the deep dives are where it gets fun.

Here is what stuck with us:
🛡️ 𝗥𝗲𝗱𝗶𝘀 𝗚𝘂𝗮𝗿𝗱𝘀 𝘁𝗵𝗲 𝗗𝗕: A 𝗦𝗘𝗧 𝗡𝗫 key blocks 9,999 losers instantly, so only real candidates reach your 𝗣𝗼𝘀𝘁𝗴𝗿𝗲𝗦𝗤𝗟 transaction.
✅ 𝗦𝗤𝗟 𝗚𝘂𝗮𝗿𝗱𝘀 𝘁𝗵𝗲 𝗧𝗿𝘂𝘁𝗵: 𝗦𝗘𝗟𝗘𝗖𝗧 ... 𝗙𝗢𝗥 𝗨𝗣𝗗𝗔𝗧𝗘 makes the row wait its turn, so two users can never both hear "booked!"
🎟️ 𝗔 𝗤𝘂𝗲𝘂𝗲 𝗧𝗵𝗮𝘁 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗤𝘂𝗲𝘂𝗲𝘀: 𝗞𝗮𝗳𝗸𝗮 keeps arrival order, and clients poll a 𝗖𝗗𝗡-cached "serving up to" number every 30 seconds instead of hammering your API.
🧹 𝗦𝗲𝗮𝘁𝘀 𝗧𝗵𝗮𝘁 𝗙𝗿𝗲𝗲 𝗧𝗵𝗲𝗺𝘀𝗲𝗹𝘃𝗲𝘀: A 10-minute 𝗱𝗲𝗹𝗮𝘆 𝗾𝘂𝗲𝘂𝗲 task checks unpaid bookings, flips the 𝗥𝗲𝗱𝗶𝘀 bit back to 0, and the seat turns green again.

If you build 𝗝𝗮𝘃𝗮/𝗦𝗽𝗿𝗶𝗻𝗴 services, this is your flash-sale, seat-reservation, and inventory playbook: @𝗟𝗼𝗰𝗸(𝗣𝗘𝗦𝗦𝗜𝗠𝗜𝗦𝗧𝗜𝗖_𝗪𝗥𝗜𝗧𝗘), 𝗦𝗽𝗿𝗶𝗻𝗴 𝗗𝗮𝘁𝗮 𝗥𝗲𝗱𝗶𝘀, and 𝗦𝗽𝗿𝗶𝗻𝗴 𝗞𝗮𝗳𝗸𝗮 do most of the work.

Have you shipped a 𝘄𝗮𝗶𝘁𝗶𝗻𝗴 𝗿𝗼𝗼𝗺 in production? Tell us what broke first 😄

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

04/10/2026

[English Below]
Hello mọi người!👋 Reactive programming là câu trả lời của Java cho vấn đề chi phí thread suốt hơn một thập kỷ qua — nhưng đánh đổi đó giờ không còn cần thiết như trước. Tại Spring I/O, Christian (type.rocks) đã có một bài chia sẻ chuyên sâu về cách Java 25 đưa 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗧𝗵𝗿𝗲𝗮𝗱𝘀, 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗖𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝗰𝘆, và 𝗦𝗰𝗼𝗽𝗲𝗱 𝗩𝗮𝗹𝘂𝗲𝘀 từ "preview feature thú vị" trở thành "bộ công cụ sẵn sàng cho production".

Nội dung chính xoay quanh ba JEP có liên quan mật thiết: các bản vá performance của 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗧𝗵𝗿𝗲𝗮𝗱𝘀, 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱𝗧𝗮𝘀𝗸𝗦𝗰𝗼𝗽𝗲 API mới, và 𝗦𝗰𝗼𝗽𝗲𝗱𝗩𝗮𝗹𝘂𝗲 — giải pháp thay thế cho 𝗧𝗵𝗿𝗲𝗮𝗱𝗟𝗼𝗰𝗮𝗹 — được demo trực tiếp trên một ứng dụng Spring Boot 4 dưới tải JMeter.

Dưới đây là những điểm nổi bật đáng chú ý:
⚡ 𝗧𝗵𝗿𝗲𝗮𝗱 𝗦𝗶𝗲̂𝘂 𝗡𝗵𝗲̣: Một virtual thread chỉ tốn khoảng 1-2 KB, so với 1-2 MB của một OS thread, giúp chạy hàng triệu task đồng thời trở thành khả thi.
🔧 𝗦𝘂̛̉𝗮 𝗟𝗼̂̃𝗶 𝗣𝗶𝗻𝗻𝗶𝗻𝗴: Java 25 chặn việc virtual threads bị "pin" vào carrier threads bên trong khối 𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗶𝘇𝗲𝗱, giúp một workload demo giảm từ 10 giây xuống còn 1 giây.
🧵 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗧𝗮𝘀𝗸 𝗦𝗰𝗼𝗽𝗲𝘀: Các lời gọi concurrent chạy song song với code đồng bộ, dễ đọc — không cần 𝗪𝗲𝗯𝗖𝗹𝗶𝗲𝗻𝘁 hay viết lại theo hướng reactive.
🔒 𝗦𝗰𝗼𝗽𝗲𝗱 𝗩𝗮𝗹𝘂𝗲𝘀: Một giải pháp bất biến (immutable), nhận biết scope, thay thế cho 𝗧𝗵𝗿𝗲𝗮𝗱𝗟𝗼𝗰𝗮𝗹, truyền đúng giá trị vào các virtual thread con được tạo trong scope.

Đối với các 𝗝𝗮𝘃𝗮/𝗦𝗽𝗿𝗶𝗻𝗴 developers, điều này có nghĩa là chỉ cần bật `spring.threads.virtual.enabled=true` là có thể đạt throughput ngang tầm reactive trên code blocking thông thường, mà không cần đụng đến database driver hay REST client.

Bạn đã thử Structured Task Scopes trên Java 25 chưa? Chia sẻ với mình dưới phần bình luận nhé.

(𝘓𝘪𝘯𝘬 𝘣𝘦̂𝘯 𝘥𝘶̛𝘰̛́𝘪 𝘱𝘩𝘢̂̀𝘯 𝘣𝘪̀𝘯𝘩 𝘭𝘶𝘢̣̂𝘯👇)

Happy learning! 👨‍💻🎉

-------

Hello everyone!👋 Reactive programming was Java's answer to the thread cost problem for over a decade — but that trade-off just got a lot less necessary. At Spring I/O, Christian (type.rocks) delivered a deep dive into how Java 25 pushes 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗧𝗵𝗿𝗲𝗮𝗱𝘀, 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗖𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝗰𝘆, and 𝗦𝗰𝗼𝗽𝗲𝗱 𝗩𝗮𝗹𝘂𝗲𝘀 from "interesting preview feature" to "production-ready toolkit."

The talk covers three connected JEPs — Virtual Threads performance fixes, the new 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱𝗧𝗮𝘀𝗸𝗦𝗰𝗼𝗽𝗲 API, and 𝗦𝗰𝗼𝗽𝗲𝗱𝗩𝗮𝗹𝘂𝗲 as the replacement for 𝗧𝗵𝗿𝗲𝗮𝗱𝗟𝗼𝗰𝗮𝗹 — demonstrated live against a Spring Boot 4 application under JMeter load.

Key advantages worth understanding:
⚡ 𝗨𝗹𝘁𝗿𝗮-𝗟𝗶𝗴𝗵𝘁 𝗧𝗵𝗿𝗲𝗮𝗱𝘀: A virtual thread costs roughly 1-2 KB versus 1-2 MB for an OS thread, making millions of concurrent tasks realistic.
🔧 𝗣𝗶𝗻𝗻𝗶𝗻𝗴 𝗕𝘂𝗴 𝗥𝗲𝘀𝗼𝗹𝘃𝗲𝗱: Java 25 stops virtual threads from pinning to carrier threads inside 𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗶𝘇𝗲𝗱 blocks, cutting a demoed workload from 10 seconds to 1.
🧵 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗧𝗮𝘀𝗸 𝗦𝗰𝗼𝗽𝗲𝘀: Concurrent calls run in parallel with synchronous, readable code — no 𝗪𝗲𝗯𝗖𝗹𝗶𝗲𝗻𝘁 or reactive rewrite required.
🔒 𝗦𝗰𝗼𝗽𝗲𝗱 𝗩𝗮𝗹𝘂𝗲𝘀: An immutable, scope-aware alternative to 𝗧𝗵𝗿𝗲𝗮𝗱𝗟𝗼𝗰𝗮𝗹 that correctly propagates into child virtual threads spawned by a scope.

For Java/Spring developers, this means enabling `spring.threads.virtual.enabled=true` can deliver reactive-grade throughput on plain blocking code, without touching your database driver or REST client.

Have you tried Structured Task Scopes on Java 25 yet? Tell us in the comments.

(𝘓𝘪𝘯𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘦𝘯𝘵 𝘴𝘦𝘤𝘵𝘪𝘰𝘯 𝘣𝘦𝘭𝘰𝘸 👇)

Happy learning! 👨‍💻🎉

Vietnam Java User Group - Vietnam JUG

13/10/2026

12/10/2026

11/10/2026

10/10/2026

09/10/2026

08/10/2026

07/10/2026

06/10/2026

05/10/2026

04/10/2026

Address

Website

Alerts

Shortcuts

Share

Category

Listing takedown request