Đây là tình huống giả định được xây dựng nhằm mục đích phân tích kỹ thuật, không phản ánh bất kỳ dự án thực tế nào tại Việt Nam.

Kính gửi các kỹ sư Việt Nam năm 2025,

Năm 2035, khi nhìn lại dòng code và kiến trúc hệ thống mà các bạn đã đặt nền móng cho BIMStorm, tôi không khỏi tự hỏi: liệu chúng ta có thực sự hiểu rõ những gì mình đang đánh đổi khi chọn real-time collaboration cho hạ tầng quốc gia? Lá thư này không phải lời ca ngợi, mà là bản kiểm điểm kỹ thuật về những quyết định đã định hình — và làm méo mó — cách chúng ta xây dựng metro số 2 TP.HCM và khu đô thị thông minh Bắc Hà Nội.

Cơ chế đồng bộ dữ liệu thời gian thực và xung đột IFC

Các bạn đã chọn WebSocket kết hợp BCF 3.0 để đẩy thay đổi hình học IFC ngay lập tức giữa các bên. Nhưng tại sao lại là real-time thay vì near-real-time với checkpoint 15 phút? Khi hai kỹ sư cùng chỉnh sửa tường chịu lực trong cùng một IFC object, vector clock của BIMStorm đã không ngăn được việc một thay đổi về thickness lan truyền trước khi geometry clash được phát hiện. Kết quả là hệ thống phải rollback theo last-writer-wins, phá hủy dữ liệu kết cấu mà không có audit rõ ràng.

Độ trễ và chiến lược mạng phân tán tại công trường

Trên tuyến metro số 2, kết nối 4G/5G thường xuyên chập chờn. Các bạn đã thiết kế hybrid edge-cloud với fallback khi mất mạng, nhưng cơ chế sync khi khôi phục lại đã tạo ra hàng loạt “ghost updates” — các thay đổi cục bộ được đẩy lên sau khi phiên bản cloud đã bị sửa bởi người khác. Tại sao không ưu tiên eventual consistency với conflict-free replicated data types (CRDT) thay vì cố gắng duy trì strong consistency qua WebSocket không ổn định? Độ trễ trung bình 800ms tại công trường Bắc Hà Nội đã khiến các kỹ sư buộc phải làm việc offline rồi merge thủ công.

Hệ thống quản lý xung đột và rollback phiên bản multi-user

BIMStorm sử dụng vector clock để đánh dấu thứ tự sự kiện, nhưng khi hai thay đổi geometry clash xảy ra trong cùng một tick, hệ thống chỉ đơn giản chọn phiên bản có timestamp lớn hơn. Điều này đã dẫn đến việc một thay đổi hợp pháp về vị trí cột chịu lực bị ghi đè bởi một chỉnh sửa thẩm mỹ từ bộ phận kiến trúc. Khi rollback diễn ra, lịch sử phiên bản không lưu lại ngữ cảnh xung đột, khiến việc truy vết trách nhiệm kỹ thuật gần như bất khả thi sau này.

Bảo mật, kiểm soát truy cập và tuân thủ Nghị định 13/2023/NĐ-CP

Kết nối với nền tảng đám mây quốc tế đã đòi hỏi granular permission và audit trail chi tiết. Tuy nhiên, việc mapping quyền theo IFC object ID đã tạo ra lỗ hổng khi một kỹ sư được cấp quyền edit structural element lại vô tình có thể truy cập metadata nhạy cảm của toàn bộ dự án. Audit trail được ghi nhận trên cloud nước ngoài cũng đặt ra câu hỏi về sovereignty của dữ liệu hạ tầng quốc gia.

Những câu hỏi kỹ thuật còn bỏ ngỏ

Năm 2035, chúng tôi vẫn đang sửa những nền tảng mà các bạn đã đặt năm 2025. Dưới đây là danh sách ngắn những câu hỏi chúng tôi mong các bạn đã giải quyết triệt để:

• Tại sao không áp dụng CRDT hoặc OT cho geometry IFC thay vì vector clock + last-writer-wins?
• Làm thế nào để hybrid edge-cloud đảm bảo consistency mà không tạo ghost updates khi khôi phục kết nối?
• Permission model cần được thiết kế như thế nào để vừa granular vừa tuân thủ tách biệt dữ liệu theo quy định Việt Nam ngay từ phiên bản đầu tiên?
• Cơ chế conflict detection cho structural element có cần được nâng lên mức hard constraint thay vì soft warning?
• Liệu real-time synchronization có đáng để đánh đổi tính toàn vẹn dữ liệu trong các dự án hạ tầng có tuổi thọ 50–100 năm?

Chúng ta không thể thay đổi quá khứ, nhưng có thể ngăn những sai lầm kỹ thuật tương tự lặp lại.

Trân trọng,
Một kỹ sư năm 2035