Chi tiết quá, thanks tác giả

Cách viết hay, dễ hiểu

Sẵn tiện cho mình hỏi chút. Giả sử hệ thống đang xài chung Group ID để share tải xử lý luồng log, mà đùng một cái lưu lượng tăng vọt. Mình không thể cắm thêm consumer vì đã bằng số partition rồi (scale thêm sẽ bị idle), cũng không thể tăng partition ngay lập tức. Trong case cháy nhà như vậy, bạn thường tuning tham số nào hay có trick gì ở tầng app để clear lượng message lag này nhanh nhất không

Bài viết bóc tách "ruột gan" HashMap cực kỳ chất lượng! Làm Java thì kiểu gì cũng phải hiểu sâu mấy vụ collision với rehashing này, không chỉ để đối phó lúc đi phỏng vấn mà lúc tuning performance hệ thống cũng rất cần. Cảm ơn tác giả, bài viết chất lượng

Bài viết cuốn thực sự. Đợt trước lúc tích hợp Redis vào project Spring Boot để làm quả caching với quản lý session, mình cũng loay hoay phân vân mãi vụ cấu hình làm sao để vẹn cả đôi đường: vừa giữ được tốc độ bàn thờ mà lỡ có sự cố cũng không lo bay màu data.

Thêm nhiều bài viết về System Design đi tác giả ơi, cách viết bài rất hay và chỉn chu

Bài viết hay, đúng thực tế mình đang gặp trong quá trình làm việc, căn bản là hay vị vội nên cứ có yêu cầu là lao vào làm

Hay quá bạn ơi, hóng phân tích thêm các design pattern khác

Giờ mới hiểu ra vấn đề, thankiu tác giả vì chia sẻ

NGUYỄN HUY HOÀNG Software Engineer

📞 Phone: 0941 280 073

📧 Email: hhoang02052004@gmail.com

Bài viết hay. Cảm ơn chủ thớt 😁

Rất vui vì bài viết giúp ích được cho bạn, thấy hay thì chia sẻ mọi người nhé

Cảm ơn sự ủng hộ và ghi nhận của bạn nhé🥰

Trước tiên cảm ơn bạn nhé, câu hỏi gãi đúng chỗ ngứa lunn. Mình khuyên thật là bạn nên "say no" với Decorator trong case này nhé. Lúc đầu bọc bọc lại thì thấy hay, nhưng tới lúc Business yêu cầu đổi thứ tự tính tiền (kiểu giảm % trước hay trừ tiền mặt trước), hoặc áp luật "dùng mã A thì cấm mã B" là code toang ngay, siêu rối. Thay vào đó, bạn cứ "vã" combo Strategy + Chain of Responsibility (kiểu Pipeline) cho mình. Tách mỗi khuyến mãi thành một Strategy độc lập, rồi cho chạy qua một cái Chain. Trúng stack Java/Spring Boot thì cứ nhét vào List rồi dùng @Order mà sắp xếp là chuẩn bài! Sau này có thêm chục cái khuyến mãi mới thì chỉ việc viết class mới, không lo đụng chạm code cũ. Bạn cứ thử hướng này xem nhé. Dự án hiện tại của bạn có dính nhiều mấy quả rule khuyến mãi "đánh nhau" (loại trừ lẫn nhau) không? 🤜🤛

Rất vui vì bài viết giúp ích được cho bạn😁

Bài viết tổng hợp rất hay và dễ hiểu, cảm ơn tác giả! Sẵn tiện đang bàn về Design Pattern, mình đang gặp một bài toán thực tế và muốn tham khảo góc nhìn của bạn. Bài toán là tính tổng tiền của giỏ hàng khi user có thể áp dụng nhiều loại khuyến mãi cùng lúc (ví dụ: giảm 10% cho thành viên VIP, giảm 50k cho đơn trên 500k, và thêm mã Freeship). Mình đang phân vân giữa việc dùng Decorator Pattern (để bọc/wrap các rule tính giá lại với nhau) hoặc kết hợp Strategy Pattern với Chain of Responsibility. Theo kinh nghiệm của bạn thì pattern nào sẽ tối ưu, dễ scale và dễ maintain hơn khi số lượng rule khuyến mãi ngày càng nhiều và phức tạp? Rất mong nhận được chia sẻ từ bạn

Khá hay và dễ hiểu

Một chủ đề không phải là mới, nhưng cách tiếp cận, đặt câu hỏi và những ví dụ đi kèm khá hay, cảm ơn công sức của tác giả

Cảm ơn tác giả đã khai sáng mình huhu

Đúng nơi, đúng người rồi đây, quá hay tác giả ơiii