Giới thiệu dự án

Sự phục hồi và tăng trưởng mạnh mẽ của ngành giao thông vận tải hành khách sau đại dịch Covid-19 đã thúc đẩy nhu cầu di chuyển liên tỉnh tăng vọt, đặc biệt trong các giai đoạn cao điểm lễ, Tết (lượng hành khách tăng từ 300% đến 400% so với ngày thường). Tuy nhiên, phương thức quản lý vận tải và bán vé truyền thống tại các bến xe lớn bộc lộ nhiều điểm nghẽn nghiêm trọng: tình trạng quá tải tại quầy vé, sai sót trong khâu điều phối luồng xe, và xung đột dữ liệu đặt chỗ (race conditions). Đồng thời, Thông tư 78/2021/TT-BTC của Bộ Tài chính quy định bắt buộc áp dụng hóa đơn điện tử có kết nối dữ liệu với cơ quan thuế từ ngày 01/07/2022 đặt ra yêu cầu cấp thiết về việc số hóa toàn diện quy trình bán vé và vận hành bến bãi.

Đồ án tốt nghiệp ngành Công nghệ Thông tin tại Trường Đại học Công nghệ Thông tin (ĐHQG-HCM) với đề tài "Xây dựng hệ thống website và ứng dụng bán vé xe khách sử dụng ASP.NET Core 5" do sinh viên Lê Hoàng Nguyên (MSSV: 19520182) và Nguyễn Lê Vinh (MSSV: 19520355) thực hiện, dưới sự hướng dẫn của ThS. Võ Ngọc Tấn, đã giải quyết trực tiếp bài toán chuyển đổi số cho mô hình quản lý bến xe hiện đại, lấy thực thể Bến xe Miền Đông mới làm trung tâm triển khai.

+-----------------------------------------------------------------------------+
|                            HỆ THỐNG BÁN VÉ XE KHÁCH                         |
+-----------------------------------------------------------------------------+
|  [Khách hàng / Mobile]       [Quầy vé / Web Admin]      [Lơ xe / Quét QR]   |
|         │                             │                         │           |
|         ▼                             ▼                         ▼           |
|  ┌───────────────────────────────────────────────────────────────────────┐  |
|  │              TẦNG XỬ LÝ DỊCH VỤ (ASP.NET CORE 5.0 MVC / API)           │  |
|  │  - JWT Authentication (HS256 + Refresh Token)                         │  |
|  │  - SignalR Hub (Real-time Seat State Synchronization)                 │  |
|  │  - Google Maps Geocoding & Local Caching Proxy Engine                 │  |
|  └───────────────┬────────────────────────────┬──────────────────────────┘  |
|                  │                            │                             |
|                  ▼                            ▼                             |
|  ┌──────────────────────────────┐    ┌───────────────────────────────────┐  |
|  │   MS SQL SERVER 2019 (ACID)  │    │     ELASTICSEARCH 7.X ENGINE      │  |
|  │   - Quản lý giao dịch vé     │    │     - Geo-point Radius Queries    │  |
|  │   - Kế hoạch tuyến & doanh thu│   │     - Index trạm dừng lân cận     │  |
|  └──────────────────────────────┘    └───────────────────────────────────┘  |
+-----------------------------------------------------------------------------+

Vấn đề cốt lõi của các hệ thống hiện hành

  1. Hạn chế trong tìm kiếm địa điểm chi tiết: Hầu hết các nền tảng bán vé hiện nay (như VeXeRe, FutaBus) chỉ hỗ trợ tìm kiếm dựa trên danh mục cố định cấp Tỉnh/Thành phố. Khi hành khách có nhu cầu đón/trả tại các cấp hành chính nhỏ hơn (đường, phường, xã, ngã ba, trạm thu phí), hệ thống không thể tự động gợi ý các tuyến xe có lộ trình đi qua lân cận.
  2. Xung đột trạng thái ghế ngồi (Double Booking): Thiếu cơ chế đồng bộ dữ liệu thời gian thực (Real-time synchronization). Khi nhiều người dùng cùng truy cập và chọn một vị trí ghế trong giờ cao điểm, hệ thống chỉ kiểm tra lại trạng thái ở bước thanh toán cuối cùng, gây ra trải nghiệm gián đoạn và tỷ lệ thất bại giao dịch cao.
  3. Giao diện thiếu tính tương thích: Nhiều cổng thông tin nhà xe địa phương sử dụng giao diện tĩnh, lỗi hiển thị responsive trên thiết bị di động, gây khó khăn cho việc tra cứu thông tin hành trình.

Mục tiêu nghiên cứu và giải pháp

Đề tài xác định 4 mục tiêu kỹ thuật cụ thể:

  1. Thiết kế kiến trúc hệ thống đa người dùng: Phân quyền chặt chẽ cho 5 nhóm tác tử (Bến xe, Nhà xe, Nhân viên quầy vé, Lơ xe kiểm tra vé qua QR code, Khách hàng).
  2. Phát triển thuật toán gợi ý trạm dừng dựa trên tọa độ không gian (Geospatial Search): Kết hợp Google Maps Places API và Elasticsearch Engine để quét trạm dừng trong bán kính $R$ so với điểm đón/trả mong muốn.
  3. Xây dựng module đồng bộ ghế thời gian thực bằng SignalR: Đảm bảo độ trễ cập nhật trạng thái ghế giữa các client $< 100\text{ ms}$, triệt tiêu hoàn toàn xung đột đặt trùng ghế.
  4. Bảo mật giao dịch và xác thực chuẩn JWT: Triển khai cơ chế cấp phát Access Token (15 phút) kết hợp Refresh Token (10 phút) và mã hóa mật khẩu bằng thuật toán băm SHA-512 có Salt ngẫu nhiên.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát thực nghiệm trên 3 hệ thống đại diện trên thị trường cho thấy các khoảng trống kỹ thuật rõ rệt:

Tiêu chí kỹ thuật VeXeRe FutaBus (Phương Trang) Xe khách Hoàng Thùy Hệ thống đề xuất (Đề tài)
Độ mịn tìm kiếm địa điểm Cấp Tỉnh/Huyện (Cố định) Cấp Bến xe/Tỉnh thành Cố định danh sách tuyến Chi tiết cấp Tọa độ / Địa chỉ / Phường xã
Công nghệ định vị lân cận Không hỗ trợ quét bán kính Không hỗ trợ Không hỗ trợ Elasticsearch Geo-point ($R$ tùy biến)
Cơ chế cập nhật sơ đồ ghế Polling khi tải lại trang Tải lại trang (Reload) Tĩnh SignalR WebSocket Push (Thời gian thực)
Khóa ghế tạm thời (Locking) Có độ trễ ($> 3\text{ s}$) Không giữ ghế khi chọn Không hỗ trợ Khóa tức thời qua Hub State ($< 100\text{ ms}$)
Xác thực API Session / Proprietary Session Based Session Based JWT (HS256) + Sliding Refresh Token
Hỗ trợ thiết bị (Responsive) Tương đối (Nhiều banner) Tốt trên App di động Lỗi vỡ khung Menu Bootstrap 5 UI + Xamarin Mobile App

Ma trận ưu tiên yêu cầu người dùng (MoSCoW)

  • Must-have: Đặt vé trực tuyến; Tìm kiếm chuyến theo khoảng cách trạm dừng; Đồng bộ trạng thái ghế qua SignalR; Quản lý kế hoạch chạy xe của Bến xe; Xác thực JWT; Phân quyền RBAC (Role-Based Access Control).
  • Should-have: Quét mã QR soát vé offline/online cho lơ xe; Tích hợp API xuất hóa đơn điện tử (chuẩn VNPT/Viettel); Báo cáo thống kê doanh thu đa chiều theo nhà xe/quầy bán.
  • Could-have: Tự động lưu cache tọa độ địa điểm Google Maps để giảm chi phí API; Tích hợp cổng thanh toán trực tuyến.
  • Won't-have (giai đoạn này): Tự động điều hướng lộ trình động bằng học máy; Dự đoán giá vé theo biến động cung cầu.

Thiết kế hệ thống

Kiến trúc tổng thể và Stack công nghệ

Hệ thống xây dựng theo mô hình phân tầng N-Tier kết hợp kiến trúc MVC (Model-View-Controller) trên nền tảng .NET 5:

  • Backend Framework: ASP.NET Core 5.0 (C# 9.0), Entity Framework Core 5.
  • Database Engine: Microsoft SQL Server 2019 (quản trị toàn bộ dữ liệu quan hệ, đảm bảo tính toàn vẹn giao dịch ACID).
  • Search Engine: Elasticsearch 7.15 (lưu trữ chỉ mục địa lý của các TRAMDUNG dưới dạng geo_point).
  • Real-time Pipeline: ASP.NET Core SignalR (truyền thông hai chiều dựa trên WebSockets/Server-Sent Events).
  • Frontend & Client: Razor Pages, Bootstrap 5.0, jQuery, Xamarin Forms (cho ứng dụng di động).
  • Cloud & Third-party Services: Google Maps Places & Autocomplete API, Firebase Storage (lưu trữ media, ảnh nhà xe, sơ đồ xe).
                      +──────────────────────────────────────────+
                      |         CLIENT TIER (Web / Mobile)       |
                      +──────────────────────────────────────────+
                                    │                │
                           HTTPS / REST API      WebSocket (WSS)
                                    │                │
                                    ▼                ▼
                      +──────────────────────────────────────────+
                      |       ASP.NET CORE 5 CONTROLLER / HUB    |
                      |  - AccountController (JWT & SHA-512)     |
                      |  - BookingController (EF Core UnitOfWork)|
                      |  - SeatHub (SignalR Persistent Channel)  |
                      |  - GeoSearchService (Elastic Client)     |
                      +──────────────────────────────────────────+
                                    │                │
                        Transact SQL Engine     Elastic REST Client
                                    │                │
                                    ▼                ▼
                      +───────────────────+    +─────────────────+
                      |  MS SQL SERVER    |    |  ELASTICSEARCH  |
                      |  (26 Tables ACID) |    |  (Geo-indices)  |
                      +───────────────────+    +─────────────────+

Thiết kế cơ sở dữ liệu (Database Schema)

Hệ thống gồm 26 bảng chuẩn hóa bậc 3 (3NF). Một số thực thể trọng tâm:

  • NGUOIDUNG (MaND [PK], TenDangNhap, MatKhau, Salt, MaLoaiND [FK])
  • NHAXE (MaNhaXe [PK], TenNhaXe, DiaChi, SoDienThoai, MaSoThue)
  • XE (MaXe [PK], BienSoXe, MaLoaiXe [FK], MaSoDoXe [FK], MaNhaXe [FK])
  • TRAMDUNG (MaTram [PK], TenTram, ViDo, KinhDo, DiaChi, MaDiaDiem [FK])
  • TUYENDUONG (MaTuyen [PK], TenTuyen, MaTramDi [FK], MaTramDen [FK], DoDaiKm)
  • KEHOACH (MaKeHoach [PK], MaNhaXe [FK], MaTuyen [FK], NgayBatDau, NgayKetThuc, TrangThaiDuyet)
  • CHUYENXE (MaChuyen [PK], MaKeHoach [FK], MaXe [FK], GioXuatPhat, GiaVeCoBan)
  • VEXE (MaVe [PK], MaChuyen [FK], MaGhe, MaHoaDon [FK], TrangThaiVe, MaQRCode)

Thiết kế bảo mật và cơ chế xác thực JWT

Quy trình xác thực được xây dựng dựa trên mô hình Stateless Token kết hợp chu kỳ làm mới an toàn:

[Client] ── (1) POST credentials ─────────────────────────► [ASP.NET Core Server]
[Client] ◄─ (2) Trả về AccessToken (15m) + RefreshPass (10m) ─ [ASP.NET Core Server]
[Client] ── (3) Gửi Request kèm Header Authorization ────► [API Service]
                 (Bearer <AccessToken>)
         ── (4) Khi AccessToken hết hạn ──────────────────► [Token Refresh Endpoint]
                 (Gửi Token cũ + RefreshPass)
[Client] ◄─ (5) Xác thực thành công -> Cấp AccessToken mới ── [ASP.NET Core Server]

Mật khẩu trước khi lưu trữ vào cơ sở dữ liệu được xử lý qua hàm băm kết hợp chuỗi ngẫu nhiên (Salt): $$\text{HashValue} = \text{SHA512}(\text{PlainPassword} + \text{Salt})$$

Phương pháp luận phát triển (Methodology)

Dự án áp dụng mô hình Agile/Scrum rút gọn kéo dài trong 14 tuần, chia thành 4 Sprint chính:

  • Sprint 1 (Tuần 1 - 3): Phân tích nghiệp vụ tại Bến xe Miền Đông mới; thiết kế sơ đồ thực thể E-R; dựng khung cơ sở dữ liệu trên MS SQL Server 2019.
  • Sprint 2 (Tuần 4 - 7): Xây dựng tầng Core API với ASP.NET Core 5; tích hợp cơ chế bảo mật JWT, SHA-512; triển khai chức năng quản lý Nhà xe, Tuyến đường, Kế hoạch lưu thông.
  • Sprint 3 (Tuần 8 - 11): Tích hợp Elasticsearch cho bài toán quét tọa độ trạm dừng; xây dựng SignalR Hub phục vụ chọn ghế thời gian thực; tối ưu giao diện Bootstrap 5.
  • Sprint 4 (Tuần 12 - 14): Phát triển module soát vé mã QR trên di động; tích hợp API vé điện tử; kiểm thử tải trọng và tối ưu hóa truy vấn.

Implementation và kết quả

Chi tiết giải thuật và mã nguồn tiêu biểu

1. Xử lý tìm kiếm trạm dừng theo tọa độ bằng Elasticsearch Geo-Distance Query

Hệ thống sử dụng bộ lọc geo_distance của Elasticsearch để tìm tất cả các trạm dừng nằm trong bán kính $R$ (ví dụ: $15\text{ km}$) xung quanh vị trí kinh độ/vĩ độ của người dùng:

public async Task<List<TramDungDto>> GetNearbyStationsAsync(double userLat, double userLon, double radiusInKm)
{
    var searchResponse = await _elasticClient.SearchAsync<TramDungDocument>(s => s
        .Index("tramdung_index")
        .Query(q => q
            .Bool(b => b
                .Filter(f => f
                    .GeoDistance(g => g
                        .Field(p => p.Location)
                        .Distance($"{radiusInKm}km")
                        .Location(userLat, userLon)
                        .DistanceType(GeoDistanceType.Arc)
                    )
                )
            )
        )
        .Sort(srt => srt
            .GeoDistance(g => g
                .Field(p => p.Location)
                .Points(new Nest.GeoLocation(userLat, userLon))
                .Order(SortOrder.Ascending)
                .Unit(DistanceUnit.Kilometers)
            )
        )
    );

    return searchResponse.Documents.Select(d => new TramDungDto {
        MaTram = d.MaTram,
        TenTram = d.TenTram,
        Distance = d.Distance
    }).ToList();
}

2. Kênh truyền thông thời gian thực SignalR Hub quản lý trạng thái ghế

Mỗi khi khách hàng click chọn hoặc bỏ chọn một vị trí ghế trên sơ đồ xe, một thông điệp được phát tức thời (Broadcast) tới toàn bộ các client đang xem cùng chuyến xe (ChuyenXeId):

public class BookingHub : Hub
{
    public async Task JoinTripGroup(string chuyenXeId)
    {
        await Groups.AddToGroupAsync(Context.ConnectionId, $"Trip_{chuyenXeId}");
    }

    public async Task LockSeat(string chuyenXeId, string seatCode, string userId)
    {
        // Kiểm tra trong bộ nhớ đệm hoặc DB xem ghế đã bị giữ bởi người khác chưa
        bool isLocked = await _seatStateService.TryLockSeatAsync(chuyenXeId, seatCode, userId);
        if (isLocked)
        {
            // Phát thông báo tới toàn bộ client trong nhóm chuyến xe
            await Clients.Group($"Trip_{chuyenXeId}").SendAsync("SeatStatusChanged", new {
                SeatCode = seatCode,
                Status = "LOCKED",
                LockedBy = userId
            });
        }
        else
        {
            await Clients.Caller.SendAsync("SeatLockFailed", seatCode);
        }
    }
}

3. Thuật toán băm mật khẩu với Salt bảo mật

public static class SecurityHelper
{
    public static string GenerateSalt(int size = 32)
    {
        byte[] saltBytes = new byte[size];
        using (var rng = RandomNumberGenerator.Create())
        {
            rng.GetBytes(saltBytes);
        }
        return Convert.ToBase64String(saltBytes);
    }

    public static string ComputeSha512Hash(string rawPassword, string salt)
    {
        using (var sha512 = SHA512.Create())
        {
            byte[] combinedBytes = Encoding.UTF8.GetBytes(rawPassword + salt);
            byte[] hashBytes = sha512.ComputeHash(combinedBytes);
            return BitConverter.ToString(hashBytes).Replace("-", "").ToLower();
        }
    }
}

Kiểm thử và đánh giá hiệu năng (Testing & Benchmarking)

  • Kiểm thử đơn vị (Unit Testing): Triển khai xUnit trên các module tính giá vé, xác thực quyền và quản lý kế hoạch xe, đạt độ bao phủ mã nguồn (Code Coverage) đạt 84.6%.
  • Kiểm thử tải trọng đồng thời (Concurrency Load Test): Sử dụng công cụ Apache JMeter giả lập 500 người dùng đồng thời gửi yêu cầu đặt vé tại cùng một mili-giây trên một chuyến xe 40 chỗ:
    • Tỷ lệ xung đột đơn hàng (Race condition / Double booking): 0.00%.
    • Thời gian phản hồi trung bình (Average Response Time): 185 ms.
    • Tần suất CPU Server duy trì ở mức an toàn: $< 62%$.
  • Độ trễ truyền nhận SignalR: Đo lường qua mạng LAN/Internet thực tế ghi nhận độ trễ trung bình chỉ đạt 35 ms trong môi trường bến xe và 85 ms trên kết nối 4G di động.
+--------------------------------------------------------------------------+
|                     KẾT QUẢ BENCHMARK TRUY VẤN ĐỊA LÝ                    |
+--------------------------------------------------------------------------+
|  Phương pháp            | Thời gian phản hồi | Mức độ phụ thuộc API ngoài|
|  ───────────────────────┼────────────────────┼───────────────────────────|
|  Google Maps Live Call  | 420 ms - 680 ms    | 100% (Tính phí request)   |
|  SQL Spatial Query      | 310 ms - 450 ms    | 0% (Tải CPU DB cao)       |
|  Elasticsearch Engine   |  18 ms -  35 ms    | 0% (Index tối ưu cao)     |
+--------------------------------------------------------------------------+

Đổi mới và đóng góp

  1. Kiến trúc dữ liệu lai (Hybrid Storage Pattern): Đề tài giải quyết triệt để bài toán dung hòa giữa tính toàn vẹn dữ liệu tài chính (ACID Transactions trên MS SQL Server) và tốc độ truy vấn không gian cực cao (Geospatial Indexing trên Elasticsearch).
  2. Chiến lược tối ưu chi phí API bên thứ ba: Xây dựng cơ chế Local Spatial Cache. Hệ thống ưu tiên truy vấn dữ liệu địa điểm nội bộ; chỉ gọi Google Maps Geocoding API khi kết quả nội bộ trả về $< 5$ bản ghi, sau đó tự động lập chỉ mục kết quả mới vào Elasticsearch. Giải pháp này giúp tiết kiệm ước tính 78% chi phí vận hành API.
  3. Triệt tiêu điểm nghẽn đặt vé cao điểm: Việc áp dụng SignalR WebSockets thay cho kỹ thuật HTTP Polling truyền thống giúp giảm tải băng thông máy chủ tới 65% trong các khung giờ cao điểm mở bán vé Tết.
  4. Đáp ứng quy chuẩn pháp lý vận tải: Module hóa đơn điện tử được thiết kế tương thích trực tiếp với các API nhà cung cấp chuẩn (VNPT-Invoice, Viettel S-Invoice) theo Thông tư 78/2021/TT-BTC.

Ứng dụng thực tế và triển khai

Kịch bản vận hành tại Bến xe Miền Đông mới

  1. Khách hàng vãng lai / Trực tuyến: Truy cập website trên điện thoại, nhập địa chỉ chi tiết (ví dụ: "Ngã tư Thủ Đức, TP. Thủ Đức"). Hệ thống tự động quét trạm dừng gần nhất và đề xuất chuyến xe chạy qua tuyến Quốc lộ 1A với thời gian dự kiến chính xác.
  2. Nhân viên quầy bán vé: Đăng nhập phân hệ POS tại quầy Bến xe Miền Đông mới, thao tác bán vé nhanh, in vé cứng hoặc gửi mã vé điện tử SMS/Email tức thì.
  3. Lơ xe / Tài xế kiểm soát cửa lên xe: Sử dụng camera điện thoại quét mã QR trên vé điện tử của khách hàng để hoàn tất thủ tục check-in trong vòng 1.5 giây mà không cần mang theo danh sách giấy.
[Khách nhập địa chỉ] ──► [Elasticsearch quét trạm lân cận (<35ms)] ──► [Chọn ghế Real-time (SignalR)]
                                                                               │
[Lơ xe quét QR Check-in] ◄── [Sinh vé điện tử / Mã QR] ◄── [Thanh toán hoàn tất (SQL Server ACID)]

Kế hoạch và yêu cầu triển khai hệ thống (Deployment Specs)

  • Môi trường máy chủ khuyến nghị:
    • OS: Ubuntu Server 20.04 LTS hoặc Windows Server 2019 Datacenter.
    • Runtime: .NET 5.0 Hosting Bundle, IIS 10 hoặc Kestrel Reverse Proxy với NGINX.
    • Elasticsearch Cluster: Tối thiểu 1 Master Node, 2 Data Nodes (RAM 8GB Heap size).
    • Database: SQL Server 2019 Standard Edition (Hỗ trợ cấu hình Always On Availability Groups).
  • Hiệu quả kinh tế (ROI): Cắt giảm 40% nhân sự trực quầy vé giờ cao điểm, loại bỏ 100% chi phí in phôi vé truyền thống nhờ vé điện tử, thời gian hoàn vốn đầu tư phần mềm ước tính trong vòng 6 đến 8 tháng.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Kết nối SignalR có thể bị gián đoạn tạm thời khi thiết bị di động của hành khách chuyển vùng dữ liệu sóng yếu (4G sang 3G) dọc đường.
  • Tập dữ liệu địa điểm ban đầu phụ thuộc vào quá trình nhập liệu ban đầu của ban quản trị bến xe và kết quả tích lũy từ Google API.

Hướng phát triển mở rộng

  • Nâng cấp nền tảng: Chuyển đổi mã nguồn từ ASP.NET Core 5 lên .NET 8/9 LTS nhằm tận dụng hiệu năng vượt trội của Native AOT và tối ưu hóa bộ nhớ.
  • Tích hợp học máy (Machine Learning): Xây dựng module gợi ý giá vé linh hoạt (Dynamic Pricing) theo thuật toán dự báo nhu cầu khách hàng theo từng khung giờ và sự kiện thực tế.
  • Đồng bộ ứng dụng di động: Viết lại ứng dụng di động cho Lơ xe và Khách hàng từ Xamarin sang Flutter / .NET MAUI để tối ưu hiệu năng đồ họa đa nền tảng.

Đối tượng hưởng lợi

  • Sinh viên & Học viên: Làm tài liệu tham khảo hoàn chỉnh về kiến trúc ứng dụng web hướng dịch vụ kết hợp nhiều hệ cơ sở dữ liệu (Polyglot Persistence: SQL Server + Elasticsearch).
  • Kỹ sư phần mềm (.NET Developers): Tham khảo mẫu thiết kế (Design Pattern) tích hợp SignalR Hub cho bài toán khóa tài nguyên đồng thời và cơ chế bảo mật JWT nâng cao.
  • Doanh nghiệp vận tải & Bến xe: Tiếp cận mô hình chuyển đổi số toàn diện với chi phí hợp lý, tuân thủ đúng quy định pháp lý về hóa đơn điện tử của nhà nước.
  • Nhà nghiên cứu: Tài liệu minh chứng thực nghiệm cho hiệu quả của việc kết hợp chỉ mục không gian Geo-point trong việc tối ưu hóa luồng tìm kiếm dịch vụ vận tải công cộng.

Câu hỏi thường gặp

1. Cấu hình phần cứng tối thiểu để triển khai hệ thống là gì?

Máy chủ Web API yêu cầu tối thiểu 4 vCPU, 8GB RAM, 50GB SSD; máy chủ cơ sở dữ liệu SQL Server yêu cầu 4 vCPU, 16GB RAM; máy chủ Elasticsearch yêu cầu tối thiểu 2 vCPU, 8GB RAM (cấu hình JVM heap size 4GB).

2. Hệ thống giải quyết xung đột khi 2 người cùng bấm chọn một ghế như thế nào?

Khi người dùng bấm chọn ghế, client lập tức gửi yêu cầu khóa qua SignalR Hub. Tại tầng ứng dụng, hệ thống sử dụng cơ chế kiểm tra trạng thái nguyên tử (Atomic Check) trong bộ nhớ phân tán kết hợp Transaction khóa dòng (ROWLOCK) trong SQL Server. Yêu cầu đến trước mili-giây sẽ được cấp quyền giữ ghế và phát thông báo LOCKED tới tất cả các máy khác; yêu cầu đến sau sẽ nhận thông báo SeatLockFailed ngay lập tức.

3. Hệ thống có thể tích hợp với cổng thanh toán điện tử (MoMo, VNPAY, ZaloPay) không?

Kiến trúc Controller-Service tách biệt của hệ thống cho phép tích hợp các SDK cổng thanh toán thông qua giao thức Webhook / IPN (Instant Payment Notification) một cách chuẩn hóa tại tầng HoaDonService.

4. Chi phí duy trì dịch vụ Google Maps API mỗi tháng được kiểm soát ra sao?

Nhờ cơ chế lưu cache kết quả tìm kiếm vào Elasticsearch và cơ sở dữ liệu nội bộ, hệ thống chỉ gọi Google API cho những địa chỉ chưa từng được tìm kiếm trước đó. Với mức hỗ trợ miễn phí $200 USD/tháng từ Google (tương đương ~10.000 lượt request), hệ thống có thể đáp ứng từ 50.000 đến 100.000 lượt tra cứu thực tế của người dùng mỗi tháng mà không phát sinh thêm chi phí.

5. Khả năng mở rộng (Scalability) của hệ thống khi lượng truy cập tăng đột biến?

ASP.NET Core 5 ở chế độ Stateless kết hợp JWT cho phép mở rộng quy mô theo chiều ngang (Scale-out) dễ dàng phía sau bộ cân bằng tải NGINX / HAProxy. Đối với SignalR, hệ thống sẵn sàng tích hợp Redis Backplane để đồng bộ các gói tin Hub giữa nhiều Web Server Node độc lập.

Kết luận

Đồ án tốt nghiệp "Xây dựng hệ thống website và ứng dụng bán vé xe khách sử dụng ASP.NET Core 5" của nhóm tác giả Lê Hoàng Nguyên và Nguyễn Lê Vinh đã giải quyết thành công bài toán chuyển đổi số mang tính thực tiễn cao tại Bến xe Miền Đông mới. Bằng việc kết hợp sáng tạo giữa nền tảng ASP.NET Core 5, động cơ tìm kiếm Elasticsearch, giao tiếp thời gian thực SignalR và cơ sở dữ liệu MS SQL Server, đề tài đã tạo nên một giải pháp công nghệ toàn diện: nâng cao trải nghiệm tra cứu lộ trình chi tiết cho hành khách, triệt tiêu xung đột đặt vé và chuẩn hóa quy trình quản lý vận tải điện tử. Đây là nguồn tài liệu tham khảo học thuật và kỹ thuật giá trị cho cộng đồng phát triển ứng dụng doanh nghiệp hiện đại.