Nội dung bài viết
Video học lập trình mỗi ngày
Bài viết này được đưa vào: Con đường của một Kỹ Sư Backend
Tháng 5/2026 chúng ta sẽ tiếp tục triển khai một dự án mới với các công nghệ mới được ra mắt nhằm giúp các anh chị join vào công ty mới có thể hoà nhập nhanh hoặc các dự án mới chuẩn bị triển khai cho năm này có lẽ họ sẽ sử dụng những framework mới và đã được thử nghiệm liên tục.
Với việc càng ngày kiến trúc microservices càng giảm theo thống kê, thì liệu đây có lẽ là một tin TỐT hay XẤU? Và khi phát triển một dự án, nếu Go và Nestjs có khuôn mẫu standard có thể dùng ngay thì JAVA lại có những yêu cầu khắt khe hơn cho việc lên structure cho một dự án ngày từ đầu, vì có lẽ nếu xài java thì họ xác định đi con đường dài.
Vì vậy, con đường go chúng ta sẽ tiếp tục đi theo layer structure, và nestjs có lẽ nên tách biệt multiple services, và giao tiếp với nhau mà TCP.
Còn java thì nếu Dự án High concurrent ~30.000 req/s chỉ tiếp cận với các lập trình viên đã có kinh nghiệm triển khai trước đó với hạ tầng của fintech or các ecommerce nhỏ thì này tôi và các anh chị sẽ đồng hành với một kiến trúc có thể nói cũng đạt được sự hùng vĩ với monolith. Đó là Spring Boot 4 + Spring Security 7 + Vue 3.
Spring Boot 4, Spring Framework 7 và Java 21+
Spring Boot 4 đã chính thức được phát hành - Hãy đọc nó tại đây nếu bạn đang tò mò về nó, dựa trên Spring Framework 7 và Java 21+ , mang đến một loạt các tính năng mới thú vị như cách khai báo HTTP Client nhanh gọn hơn trước rất nhiều , xử lý đồng thời có cấu trúc và tăng tốc độ khởi động lên 30%. Spring Security cũng đã được nâng cấp lên phiên bản 7.x , với hỗ trợ MFA tích hợp và cấu hình DSL thanh lịch hơn.
Kết hợp với Vue 3 Composition API , sự kết hợp mạnh mẽ này sẽ cải thiện đáng kể kiến trúc dự án mà tháng 5 chúng ta sẽ khởi động sau kỳ nghỉ lễ.
Tôi hy vọng rằng khi join vào công ty or ít nhất trong CV của bạn, bạn hãy thêm nó vào như là một phần dự án mà bạn là người đứng đầu. Hãy khiêm tốn khi apply vào CV bởi những người review CV cho vị trí BE không phải là những tay mới vào ngành nghề đâu. Họ nhìn và phán đoán rất chuẩn dù rất ít các error được đưa ra...
Ở đây, tôi không nghĩ bạn cần phải là senior. Mà ở đây bạn cũng có thể từ FE mobile qua BE cũng có thể làm được điều này, bạn chỉ cần tập trung để hiểu biết những điều sau đây:
- Khái niệm thiết kế kiến trúc tách biệt hoàn toàn giữa giao diện người dùng và hệ thống máy chủ.
- Các phương pháp tốt nhất để xác thực không trạng thái JWT trong Spring Security 7
- Triển khai thanh lịch mô hình phân quyền RBAC
- Một giải pháp hoàn chỉnh cho xác thực giao diện người dùng trong Vue3.
- Một số bài học rút ra từ những sai lầm (tất cả đều từ những trải nghiệm đau đớn, có đền tiền...) khi tham gia những dự án CCU... Mà tôi chuẩn bị ghi ra...
Tech Stack
| Layer | Technology Choice | Version | One-Sentence Comment |
|---|---|---|---|
| Backend Framework | Spring Boot | 4.0.x | Java 21+, blistering takeoff speed. |
| Security Framework | Spring Security | 7.x | Finally, truly SPA-friendly. |
| Persistence Layer | MyBatis-Plus | 3.5.x | Write as little SQL as possible. |
| Database (Primary) | MySQL | 8.x | Proven reliability for core business data. |
| Database (Advanced) | PostgreSQL | 16.x | Powerful features for complex relationships. |
| Cache | Redis | 7.x | A perfect helper for Token blacklisting. |
| Frontend Framework | Vue | 3.5.x | The Composition API is absolutely amazing. |
| Build Tool | Vite | 6.x | So fast it’s almost a blur. |
| HTTP Client | Axios | 1.x | Interceptors are the GOAT. |
| UI Components | Element Plus | 2.x | The top choice for enterprise-grade apps. |
| Authentication | JWT | - | Stateless, naturally suited for distributed systems. |
Các bạn hãy xem trên đây những vũ khí nào bạn đã quen thuộc với điều đó....
Cạm bẫy với Redis
Tôi thấy rất nhiều channel nói về ưu điểm của Redis, và tôi không hề phủ nhận điều đó. Nó đã hỗ trợ rất tốt cho các system của chúng tôi. Nhưng cũng không ít lần nó làm thiệt hại đến công việc triển khai dữ liệu xuyên suốt. Đây là một trong 3 vấn đề khi chúng ta sử dụng với cache..
Hãy xem code của một anh chàng junior bên chúng tôi triển khai phần mềm logitics.
public User getCustomerById(Long customerId) {
// 1. Get data from Redis
String customerJson = redisTemplate.opsForValue().get("customer:" + customerId);
if (customerJson != null) {
return JSON.parseObject(customerJson, Customer.class);
}
// 2. Get data from postgreSQL
Customer customer = customerMapper.selectById(customerId);
// 3. Set data to Redis
redisTemplate.opsForValue().set("customer:" + customerId, JSON.toJSONString(customer), 1, TimeUnit.HOURS);
// 4. Response to Controller...
return customer;
}
Theo quy trình hoạt động của [Git Workflow - Tất cả các lập trình viên phải bắt buộc quen thuộc với nó] thì tôi nhận được một FEAT này thì sẽ review và thoạt nhìn có vẻ không có vấn đề gì? Nhưng khi xem xét kỹ hơn đó là:
- Nếu ai đó cố ý yêu cầu một customerId không tồn tại (ví dụ: -1, -2, v.v.), lúc này cơ sở dữ liệu sẽ bị truy vấn mỗi lần...
- Một lượng lớn yêu cầu đồng thời truy cập vào cơ sở dữ liệu ngay khi một
hot keyhết hạn. - Một lượng lớn
keyshết hạn cùng lúc, ngay lập tức làm quá tải cơ sở dữ liệu...
Bạn nên dừng lại đây và thử nghĩ xem, 3 vấn đề trên trong ngôn ngữ system design thì sẽ được gọi là gì? Tôi nghĩ bạn nên biết, vì đôi lúc họ giao tiếp với nhau bằng những term ngắn ngửi như: "Cách này vi phạm idempotant..." Lúc này bạn nghĩ gì? Search đúng không? Không nên, vì vậy cố gắng theo dấu chân ở đây... Và chú ý đừng nôn nóng cách xử lý... Tôi sẽ show ngay bây giờ
Solution 1: SỐC: Distributed Cache Redis đã phản bội chúng tôi, 1 tỷ thất thoát ở ngày bán vé thứ hai
Solution 2: Redis Cache Penetration: Backend xuất sắc đã xử lý 100 triệu requests như thế nào? (Cạm bẫy 1)

