Pay Toll - A High-Concurrency Backend Architecture for Smart RFID Toll Collection

Overview

"Pay Toll" is an enterprise-grade hardware and software solution engineered to automate toll plaza operations. From a backend perspective, the system requires a highly concurrent, fault-tolerant architecture to process real-time telemetry from IoT edge devices via RESTful APIs. The backend is designed using Java ecosystem standards to ensure robust transaction processing, utilizing multithreading design patterns to handle high-throughput vehicle ingress and dynamic congestion control.

Hardware Data Ingestion & Fault Tolerance

The hardware design dictates how data enters the Java backend, requiring resilience for both online and offline scenarios.

Online Mode (Standard Ingestion) During normal operation, the RFID scanner reads the tag (105) and passes data to the Arduino microcontroller (103). This payload is transferred via I2C protocol to the Node MCU (102), which acts as a WiFi-enabled edge node sending HTTP/MQTT requests to our Cloud Storage and backend server.

Fig. 100 Hardware architecture in presence of Internet connection

Offline Mode (Asynchronous Batch Processing) A critical architectural requirement is maintaining operational continuity during connectivity loss (306). Data is instead routed to a remote computer (307) via a serial interface (308), generating a .csv file (309).\

To handle the manual upload (310) of this .csv to the database (311), the Java backend exposes a secure multi-part file upload API. The backend utilizes the Worker Thread Pattern: a ScheduledExecutorService (or Spring Batch job) processes the file stream in parallel chunks, ensuring the main thread doesn't block while data is synchronized with the central database.

Fig. 300 Hardware architecture in absence of Internet connection

Integrated System & Multithreading Patterns

To handle concurrent requests from multiple toll plazas without thread starvation, the system heavily relies on concurrency utilities.\

Producer-Consumer Pattern: The Node MCU produces scanned RFID payloads. The Java backend implements a BlockingQueue and an ExecutorService thread pool to consume requests asynchronously. Worker threads validate the tag, update the database, and return commands to open the servo motor.
Observer Pattern (Congestion Management): A daemon thread continuously aggregates vehicle density data. Upon reaching a threshold, the backend acts as a subject, notifying registered Node MCUs to open another lane gate.

Fig. 200 Integrated model of the proposed system

Application Workflow & API Delivery

The server exposes a secure REST API (Controller layer) consumed by the cross-platform Website and Mobile Application. Features like "Add Money" or "Pay in Advance" require external payment gateway integration. These I/O-bound operations use CompletableFuture, allowing the server to process Net Banking transactions non-blockingly, keeping the main thread responsive.

Fig. 600 Detailed or step-by-step website/mobile application

Database Design & ORM Implementation

The persistence layer is mapped using Java Persistence API (JPA) entities, adhering to the UML and E-R architecture.

UML Controllers: The User actor hits endpoints for viewing maps, filing reports, and checking balances, while the Admin actor fetches data for monitoring toll plazas and viewing user details.
Concurrency Control (E-R Model): Users and Wallets share a @OneToOne mapping. To prevent race conditions during concurrent wallet updates, Optimistic Locking is applied to the Wallets entity. Details and Vehicle Type are mapped via @ManyToOne, and the @ManyToMany relationship between Users and Transactions ensures ACID compliance. All entities rely on an auto-incremented primary key (id).
Fig. 400 UML diagram of the proposed model

Fig. 500 E-R Diagram of the proposed model