AbuDiyab

AbuDiyab is one of the older car rental businesses in Saudi Arabia, founded in the late 1960s and still family-run, and this is the platform its rental operation runs on. The numbers set the shape of the problem: more than eight thousand vehicles, over fifty branches across twelve cities and four main airports, and more than half a million customers. It operates in a market that describes itself as the meeting point of three continents, and the product shows it: branches inside four airports, an Umrah rental mode timed to pilgrimage rather than to a calendar, and one-way rentals that move cars between regions. Customers reach it through an Angular website and a Flutter mobile application, with an administration dashboard behind them where the business is actually run: fleet and bookings, reporting, and the finance side that turns a closed rental into a cleared tax invoice. Behind them sit the things a rental business is actually made of: a fleet that turns over every eighteen months, branches that hold and exchange vehicles, and a tiered membership scheme that changes what a car costs.

Availability is not a number, and that is the whole difficulty. Whether a car can be rented depends on where it physically is, what rental it is currently on, when it is due back, and whether it is in service, so answering what is available at a branch for a future date range is an interval query against thousands of independently changing assets that must never double-book. One-way rentals sharpen it: a car picked up in Riyadh and dropped in Jeddah has moved inventory between two branches, changing availability at both ends. Five rental modes ask that question differently again. A daily rental starts at a branch, a delivery booking has no pickup branch at all, an airport booking is scoped to a terminal, a monthly package holds a car for weeks rather than days, and an Umrah rental is bounded by a pilgrimage season rather than a calendar. Underneath all of it the fleet is physical: cars are damaged, serviced, moved and delayed by people, so the record drifts from reality unless something actively pulls it back.

The platform carries the customer journey and the operation behind it on one fleet. Customers search by region and branch, filter across fourteen body categories from economy to bus, and see each vehicle with its model year, transmission, seats, luggage, fuel grade and daily kilometre allowance, priced with any coupon that applies to that category. Booking runs branch, dates, vehicle, payment. Alongside daily rental sit monthly packages, delivery, airport collection and an Umrah mode, plus a separate limousine product booked by trip or by the hour with a destination rather than a branch. A four-tier membership scheme sits across all of it, so the same car costs different customers different amounts: each tier carries a rental discount, additional kilometres, additional hours and half-price inter-region drop-off, and points earned on bookings pay down daily rental. Closing a rental produces a tax invoice, and in Saudi Arabia that is a regulated act rather than a formality: invoices are generated to the ZATCA e-invoicing standard and cleared with the authority itself. The operational side covers vehicles, bookings, customers and branches with the pickup and drop-off workflows between them,.

The topology follows the fleet rather than the customer. A web client and mobile applications reach one backend, and behind it sit the three things every rental question resolves against: the fleet and its availability, the branches that hold and exchange vehicles, and the pricing that turns a vehicle and a date range into a number for a particular customer. Underneath is a Laravel 10 backend, modular rather than monolithic in one piece, running on Octane over MySQL with Redis in front of the reads that repeat, deployed to an Amazon EKS cluster on AWS. Three surfaces reach it: a Flutter application, an Angular website and an administration dashboard. The two customer surfaces carry the same journey; the dashboard carries everything the customer never sees. Two integrations reach outward and they fail differently. Firebase carries push, and a missed notification is an annoyance. ZATCA sits on the money path, and an invoice that has not cleared is not an invoice. What remains unrecorded is how availability is computed and cached, and how reservation consistency is enforced under concurrency.

• Availability is an interval query rather than a stock check, and every other decision follows from accepting that. A counter can be decremented; a fleet cannot, because a vehicle is available for a date range only in the gaps between the rentals already booked against it, offset by where it physically is and whether it is roadworthy. The question a customer asks, what can I rent from this branch next Tuesday, is a search across thousands of assets with individual timelines.
• Five rental modes are not five variations on one query. A delivery booking has no pickup branch, an airport booking is scoped to a terminal rather than a city, a monthly package removes a vehicle from the daily pool for weeks, and an Umrah rental is bounded by a religious season rather than by a date picker. The limousine product does not use branches at all, booking by trip or by hour against a destination. One fleet has to answer all of them without any of them being a special case bolted on.
• A fleet refreshed every eighteen months is a conveyor rather than a set. Vehicles enter, serve, and leave to used-car sales, so availability has a horizon past which a given car may no longer be in the business at all. Long-term corporate leases pull in the same direction from the other end, removing vehicles from daily availability for months at a time, which means the pool a customer searches is smaller than the fleet and shifts for reasons the customer never sees.
• Membership makes price a property of the customer rather than of the car. Four tiers each carry a discount, additional kilometres, additional hours and half-price inter-region drop-off, and coupons apply to some vehicle categories and not others, and expire. A quoted price therefore resolves from vehicle, duration, rental mode, membership tier and coupon together, and it has to hold between the moment it is shown and the moment it is paid.
• Points are money-adjacent without being money, which shows up as a set of rules the ledger has to enforce rather than describe. They pay down daily rental but explicitly not damages, shipping fees, traffic violations or travel authorisation, so the ledger has to know what kind of charge it is being applied to. Blacklisting a customer cancels their points outright, which makes the balance revocable by an administrator rather than owned by the person who earned it.
• One-way rentals make branch inventory a flow problem rather than a stock problem. Every inter-region drop-off moves a vehicle from one branch to another without anyone deciding it should live there, so over time the fleet distributes itself according to customer demand rather than operational need, and something has to notice and correct it.
• Tax compliance sits on the critical path of finishing a rental, which is an unusual place to find a third party. Under the Saudi e-invoicing regime an invoice is not simply generated and filed: it is produced as structured XML, cryptographically stamped, carried with a QR code and cleared with or reported to the authority. A government service is therefore a dependency of closing a contract, and its availability is a property of the business rather than of the integration.
• The invoicing pipeline was built twice. It started at the generation phase, producing compliant invoices locally, and was extended to the clearance phase when live integration with the authority became mandatory. That is a migration performed on the part of the system that cannot lose a record, against a deadline set by a regulator rather than by a roadmap, while the business kept issuing invoices throughout.

• Availability as an interval query across thousands of independently changing vehicles, with no double-booking
• Five rental modes plus a limousine product asking differently shaped availability questions of one fleet
• One-way rentals redistributing branch inventory as a side effect of customer demand
• A fleet on an eighteen-month refresh cycle, entering and leaving the business continuously
• Pricing that resolves from vehicle, duration, mode, membership tier and coupon together
• A points ledger that must distinguish rental charges from damages, fines and fees, and be revocable
• A physical fleet whose real state drifts from the record through damage, service and delay
• Regulated e-invoicing on the critical path of closing a rental, migrated from generation to live clearance while in service
• One backend serving two customer surfaces and an administration dashboard that spans operations, reporting and finance

• ZATCA: Saudi e-invoicing, across both the generation and clearance phases
• Firebase: push notification delivery to the mobile applications
• Payment: multiple methods offered at checkout; the gateways are not recorded

• Laravel 10
• Laravel Octane
• MySQL
• Redis
• Flutter
• Dart
• Angular
• TypeScript
• Firebase
• ZATCA e-invoicing
• AWS
• Amazon EKS
• Docker