Abokabot adopts a Client-Server Architecture with a layered backend. This section justifies the choice and presents the high-level system diagram.
Justification for selecting Client-Server over alternatives like Peer-to-Peer or Event-Driven microservices.
Client-Server centralizes card validation rules on the server. When Menged updates its API or fare policies change, only the server needs updating. Client apps receive the new behavior transparently, preventing inconsistent validation across devices.
All boarding terminals communicate with the same authoritative server. Fare deductions are serialized through a single transaction coordinator, preventing race conditions where two terminals might both approve a card with insufficient balance.
The server acts as a trust boundary. Clients never communicate directly with Menged or the database. All sensitive operations pass through the API gateway, where authentication tokens are verified and requests are rate-limited.
Stateless application servers allow horizontal scaling. During peak commuter hours, additional server instances spin up behind the load balancer. Client apps are unaffected as they only ever address the gateway endpoint.
System components, communication flows, and Menged integration points.
Passenger mobile apps, operator dashboards, and NFC-enabled boarding terminals. All communicate exclusively via HTTPS REST to the API Gateway.
Stateless microservices behind an API Gateway: Auth, Ticketing, Fare Calculation, Route Management, and Admin. Each service has bounded responsibility.
PostgreSQL for transactional data, Redis for session and route caching, and an append-only audit log store for compliance and forensic tracing.
External Menged API Gateway called exclusively by the Ticketing Service over TLS. Responses are cached briefly in Redis to reduce latency on consecutive taps.