Cab booking end to end (Uber & Ola)

Drivers send location pings every few seconds into an ingest service that updates an in-memory geo index keyed by H3 cell, sharded by city. On a request, I look up the rider's cell and neighbouring rings, filter by vehicle type and availability, then call the routing engine for road ETA and rank. I offer to one driver at a time with a short timeout, or batch requests over a small window to optimise globally. Acceptance is a conditional update: set the trip's driver only if the trip is unassigned and the driver's status is available, using a version check or compare-and-set. If it fails, the driver gets a 'trip taken' message and matching moves on. Driver status is locked during an offer so they are not offered two trips.

I model the trip as an explicit state machine: REQUESTED, DRIVER_ASSIGNED, DRIVER_ARRIVED, STARTED, COMPLETED, with CANCELLED reachable from defined states. Each row carries a version number. Every transition is a conditional write such as 'set state to STARTED, version to 6, where trip_id matches, state is DRIVER_ARRIVED and version is 5'. If the condition fails, the caller re-reads and decides. Illegal transitions are rejected in one service, not in each client. Each transition also appends an immutable trip event through a transactional outbox, so billing, notifications, tracking and analytics consume a reliable ordered stream per trip. Keying that stream by trip ID keeps ordering, and the version lets consumers drop duplicates or stale events.

The fare service stores each quote server-side with a quote ID, rider ID, vehicle type, pickup and drop, route estimate, rate card version, surge multiplier and expiry. The client only holds the ID. Booking must reference a valid, unexpired quote owned by that rider. Otherwise the rider gets a fresh quote and confirms again. The trip snapshots the quote rules, so later changes to the rate card or surge do not affect it. At drop, the final fare is calculated from those snapshotted rules. Only whitelisted adjustments are added, such as a rider-initiated drop change, waiting beyond the free window, or tolls, and each has an evidence trail. Anything outside the rules is capped or sent for review, never silently charged.

The client generates a unique key, such as a UUID, when the rider taps Book. It sends the same key on every retry of that intent. The booking service does an insert-if-absent on a table keyed by rider ID and idempotency key, storing the resulting trip ID and response. If a double tap or a network retry arrives, the unique constraint fails and the service returns the original trip instead of creating a new one. If the same key arrives with a different payload, it returns an error. Keys expire after a reasonable window. A second guard is useful too: allow only one active trip per rider per product, enforced with a unique partial index or a conditional write.

Driver apps send pings every few seconds over a persistent connection to a stateless gateway. Pings go into a partitioned log such as Kafka, keyed by driver ID so each driver's updates stay ordered. A location service consumes them, drops out-of-order or implausible points, and updates an in-memory geo index. That index maps H3 cell to available drivers and driver to their latest position, status and timestamp. Entries carry a TTL, so drivers who go silent disappear from matching automatically. The index is sharded by city or cell range. Raw pings are written asynchronously to cheaper storage for fare audit, disputes and ETA model training. The hot path never waits on durable storage.

SOS goes on a separate, priority path. The app sends it over multiple channels: the live socket, an HTTPS call with retries, and SMS as a last resort if data is unavailable. Each SOS has a client-generated ID, so duplicates collapse. The server persists it durably with synchronous replication before acknowledging. The app keeps retrying until it gets that acknowledgement and shows the rider clear status. The SOS service runs on dedicated capacity, isolated from surge-time traffic, with its own queue and alerting. It triggers the safety team console, notifies emergency contacts, attaches live location and trip details, and offers a one-tap call to the national emergency number 112. Unacknowledged cases escalate automatically, and the path is tested with regular drills.

I would use these entities. Rider and driver profiles. Vehicle. Quote, with its ID, rules snapshot, surge and expiry. Trip, holding state, version, rider, driver, quote reference, pickup, drop and timestamps. TripEvent, an append-only history. Payment intent and ledger entries. Rating. SOS case. Trips and payments need strong consistency, so they go in a relational or NewSQL database sharded by city or trip ID. Live locations and driver availability sit in an in-memory geo store with TTL. Trip events flow through Kafka to a data lake for analytics. Raw GPS traces go to object storage or a time-series store. The quote and rate cards are cached, but the source of truth stays in the database.

Surge reflects the imbalance between demand and supply in a cell over a recent window. I count open requests and app opens against available drivers per H3 cell, smooth the ratio over time and across neighbouring cells, and map it to a multiplier with caps set by policy and, where applicable, local regulation. Fairness comes from three things: the rider sees the multiplier before booking, the quote is locked with an ID and expiry, and the multiplier changes gradually so it cannot jump between two taps. I'd log every quote with its inputs so disputes and regulator questions can be answered, and monitor for zone gaming by drivers going offline to trigger surge.

Fare calculation happens server-side from the locked quote plus allowed adjustments like waiting time and tolls, so the client never decides the amount. For UPI and cards, I create a payment intent with an idempotency key tied to the trip, and treat the PSP webhook or a status poll as the source of truth, not the app callback. Failed digital payments become dues on the rider account, collected on the next ride. Wallets use a double-entry ledger. Cash is common for autos and bikes in India, so the driver collects it and the platform posts its commission as a debit on the driver's ledger, recovered from future online earnings or payouts. Reconciliation jobs match ledger entries against PSP settlement reports daily.

I would state my assumptions instead of quoting real figures. Say there are one million drivers online at peak, each pinging every four seconds. That is about 250,000 writes per second. At roughly 100 bytes per ping, that is around 25 MB per second of ingest, or about 2 TB per day of raw data before compression. Each update is a small in-memory operation, so a few dozen index shards partitioned by city handle it comfortably, with headroom for festivals and rain. Kafka partitions are sized to the consumer parallelism. Load can also be cut by adapting the ping rate: send less often when the driver is stationary or offline, and more often on an active trip.

The matching engine picks a candidate and marks a short-lived offer reservation on that driver, so they are not offered two trips at once. The offer goes over the driver's persistent socket through the gateway that owns the connection, found via a connection registry. If the socket is down, a push notification is sent. The offer has a server-side deadline. A timer service or delayed queue expires it, releases the reservation and moves to the next ranked driver. Acceptance is one conditional update: set the driver on the trip only if the trip is unassigned and the driver is still free. Declines and timeouts are recorded for acceptance-rate metrics, and the rider sees 'finding driver' until assignment or a final no-drivers result.

Greedy matching gives each request the best driver available right now. It is simple and fast, but in dense areas it can be globally poor. One rider takes a driver who would have been ideal for another rider, leaving the second rider a long pickup. Batching collects requests and drivers over a short window, a few seconds at most, and solves a bipartite assignment that minimises total ETA. Hungarian-style or min-cost-flow solvers are typical. The trade-off is the added wait and extra compute. I would batch in dense, high-demand cells where gains are real. In sparse areas or for latency-sensitive products I would fall back to greedy. The window should be tuned with experiments against pickup ETA and completion rate.

Straight-line distance ignores one-way streets, flyovers, rivers, U-turn restrictions and traffic. A driver 400 metres away across a divided highway can take longer than one 1.5 km away on the same side. Road ETA reflects what the rider actually waits for. Computing it for every candidate is expensive, so I prefilter by H3 rings and haversine distance to a small set, perhaps the nearest ten to twenty. Then I call the routing engine with a one-to-many matrix query using precomputed contraction hierarchies plus live traffic weights. Cell-to-cell ETAs are cached for short periods, and the system degrades to cached or distance-based ranking if routing is slow.

The location service publishes each active-trip driver position to a channel keyed by trip ID. Rider apps subscribe over a WebSocket or server-sent events through edge gateways. Share-link viewers use the same channel through a read-only, tokenised endpoint that expires when the trip ends. Updates are throttled to what the map needs, and the client smooths movement by snapping points to the route and interpolating between them. Missing updates are fine because each message carries absolute position and timestamp, so there is no need for guaranteed delivery. If push breaks, the client falls back to polling. Share tokens reveal only the trip's live data, never the rider's history or contact details.

At trip start I store the expected route and ETA. A stream processor consumes GPS pings for active trips and compares them against that route. It flags sustained distance from the corridor, a long stationary period in an unexpected spot, a sudden ETA jump, or the trip going far past the drop. Short deviations caused by traffic or a valid reroute are tolerated using thresholds and recomputed routes. When a rule fires, the rider gets an in-app safety check-in. If there is no response or the rider asks for help, it escalates to the safety team. Thresholds are tuned per city to avoid alert fatigue, and every check is logged for audit.

The trip is completed, but the payment sits in a PENDING state with a payment intent ID. I never mark it failed just because the client timed out. The payment service relies on the gateway webhook and also runs status-check polling with backoff, because webhooks can be delayed or lost. If it succeeds, the ledger is posted and the receipt is sent. If it fails, the rider is asked to retry or pay by another method, and the amount is recorded as dues on the next booking per policy. Collection calls use idempotency keys so a retry never debits twice. Daily reconciliation against gateway settlement files catches any mismatch, and any double debit triggers an automatic refund.

I use a double-entry, append-only ledger. On an online trip the platform collects the fare, so the driver account is credited the fare minus commission and taxes, then paid out on a schedule. On a cash trip the driver already holds the money, so the ledger debits the driver for the platform's commission. Their balance can go negative. Each entry references the trip ID with a unique key, so retries never double-post. Balances are derived from entries or maintained with versioned conditional updates. Negative balances are netted against future online earnings or settled through driver top-ups. Policy can limit cash trips when dues exceed a threshold.

Ride-hailing is naturally local. A rider in Pune never needs a driver in Chennai, so I shard matching, the geo index and surge by city or region. That gives locality, isolates failures and allows per-city tuning. The downside is skew: metro cities are much hotter than small ones, so large cities are further split by H3 cell ranges, with handling for boundary rings that cross shards. Trips that cross boundaries, like airport runs into a neighbouring district, are owned by the pickup city. Global entities such as user accounts, payment instruments and the ledger are sharded by user ID instead. A routing layer maps each request to the right shard.

The driver app keeps recording GPS points locally, with timestamps, while offline. When connectivity returns it uploads them in a batch, and the server orders them by timestamp to rebuild the path for fare calculation. On the server, a missing heartbeat does not cancel the trip. It moves into a 'connection lost' sub-state. The rider's map shows the last known position and a notice. If the gap lasts too long, the safety system checks in with the rider. End-trip actions taken offline are queued with idempotency keys and replayed. If the GPS gap is large, the fare falls back to the routed distance between known points, capped by the quote rules, so the rider is never overcharged because of missing data.

Drivers may spoof location to look closer for offers, or create fake trips to collect incentives. On the device side, I check for mock-location flags, rooted devices and app integrity signals, such as the Play Integrity API. On the server side, I look for impossible speeds or jumps, pings that stay too perfect or too static, mismatches between GPS and network-derived location, and routes that do not follow roads. For collusion, I watch for repeated rider-driver pairs, very short trips near incentive thresholds, and shared devices or payment instruments. Suspicious trips get their incentives held, not paid instantly. Scores feed a review queue, because hard blocks on noisy signals would hurt honest drivers in poor-GPS areas.

Each driver has a status: OFFLINE, AVAILABLE, OFFERED, ON_TRIP. The source of truth is in a strongly consistent store with a version number. The geo index is a fast but possibly stale copy. Index entries expire via TTL if pings stop, so drivers who closed the app or lost signal drop out. When a driver takes a trip, the status changes in the source of truth first, and the index is updated from that event. Because the index can lag, matching treats it only as a candidate list. The final conditional assignment write rechecks real status. Drivers who also run other apps are handled the same way: if they do not respond, the offer times out and repeated timeouts lower their priority.

Phone numbers are masked. Calls and chats go through a proxy number or in-app VoIP, and that link is cut shortly after the trip. The driver sees the pickup point and rider first name, not saved addresses or history. Precise location is collected for the trip's purpose and kept only as long as policy and law require. India's DPDP Act 2023 requires a clear notice, consent tied to a purpose, and support for user rights. Data is encrypted in transit and at rest, with access based on role and audited. Support staff see masked data unless a case justifies more. Analytics use aggregated or pseudonymised data. Share links are tokenised and expire.

Cancellation rules sit in a versioned policy engine, configured per city and product, and the policy version is stored on the trip. Inputs come from trip events: time since assignment, whether the driver arrived, the driver's ETA at booking versus actual movement, and who cancelled. A rider cancelling inside the grace window pays nothing. After the window, or after a verified arrival, a fee applies. If the driver was not moving toward the pickup or arrived far later than promised, the fee is waived. Arrival is verified with GPS near the pickup point, not just a button tap. Drivers who repeatedly cancel are penalised. Every fee comes with a reason shown to the user, and disputes go to support with the full event history.

After completion, each side gets a rating prompt linked to the trip ID. A rating can only be submitted by a trip participant, and only once per trip, enforced with a unique key. Ratings flow as events into an aggregation service. That service keeps a rolling average over recent trips, so the score reflects current behaviour and old outliers fade. Low ratings ask for structured reasons, and safety-related reasons route to the trust and safety team. To limit abuse, I exclude ratings from trips under fraud investigation and detect retaliation patterns. Raw scores are not shown in a way that reveals who rated whom. Drivers below a threshold get coaching before any deactivation review.

I run active-active or active-standby across at least two regions. Trip and ledger data are replicated synchronously within a region and asynchronously across regions, with a clearly stated RPO. The geo index is soft state. After failover it rebuilds within seconds from fresh driver pings, so it does not need replication. Clients reconnect through global load balancing to the healthy region. Trips in flight continue because their state and quote snapshot are in replicated storage, and idempotent APIs make retries safe. To avoid double assignment during a split, each city shard has exactly one writer at a time, enforced by leases or fencing tokens. Failover is drilled regularly, not just documented.

Raw GPS in dense Indian streets can be off by tens of metres, and a pin in the middle of a building or a flyover wastes minutes. Snapping moves the pin to a nearby point the driver can actually reach. Candidates come from road segments, known gates and entrances, and pickup spots learned from past successful pickups. The rules respect one-way streets and the side of the road. Saved places store the confirmed snapped point. The rider sees the suggested spot and can adjust it, and the final point is what goes into the quote and matching. Good snapping reduces the back-and-forth calls and cancellations that hurt both ETA and ratings.

I use the transactional outbox pattern. In the same database transaction that updates the trip state and version, the service writes an event row to an outbox table. A relay, or change-data-capture with something like Debezium, reads the outbox and publishes to Kafka, partitioned by trip ID for ordering. This avoids the dual-write problem, where the database commits but the message is lost, or the reverse. Delivery is at-least-once, so consumers such as billing, notifications and rewards are idempotent. They track the last processed version per trip or keep a processed-event table. Poison messages go to a dead-letter topic with alerting, rather than blocking the partition.

User-facing SLOs: quote latency, time from booking to driver assigned, assignment success rate, live-tracking freshness, payment success rate, and SOS acknowledgement latency, which gets the strictest target. System metrics: location ingest lag, geo index staleness, offer acceptance and timeout rates, routing engine latency, socket connection counts per gateway, and outbox relay lag. Correctness monitors: zero drivers on more than one active trip, final fare above quote-rule limits, and ledger imbalance after reconciliation. Each correctness check alerts immediately. Everything is sliced by city and product, because a citywide outage in one place can hide inside national averages. Distributed tracing by trip ID connects all services for debugging.

A scheduled ride is stored as a reservation with pickup time, locations, vehicle type and a fare estimate or locked quote, depending on product policy. Real-time matching cannot happen hours ahead, so a scheduler triggers the normal matching flow some minutes before pickup. It may start earlier for airports or areas with sparse supply. Optionally the platform pre-assigns a willing driver who commits to the slot, with a fallback to live matching if that driver drops. The scheduler must be durable and idempotent, so a crash or a duplicate trigger never creates two trips. The rider is notified when the driver is assigned, and if no driver is found by a cutoff the system escalates rather than failing silently.

Several layers help. Surge in the affected cells balances demand and supply. Airports often use a driver queue with first-in-first-out fairness and designated pickup zones instead of pure nearest matching. Infrastructure for known events, such as festivals, IPL matches and New Year's Eve, is pre-scaled per city based on history. Autoscaling handles unexpected spikes like monsoon rain. When overloaded, the system sheds non-critical work, such as analytics writes, high-frequency map updates and promotions, while protecting booking, matching, payments and SOS. Clients back off with jitter so retries do not snowball. Rate limits per user and per device stop retry storms.

First, offline replay on historical request and supply logs, though this cannot capture how drivers react. Second, shadow mode in production: the new algorithm computes assignments alongside the old one without acting on them, so we can compare predicted ETAs and check latency. Third, an online experiment. Because riders and drivers in a city compete for the same pool, user-level A/B tests leak between groups. So I use switchback tests, alternating algorithms by city or cell over time windows, or randomise by geography. Guardrail metrics include pickup ETA, cancellation rate, driver earnings and completion rate. Rollout is behind a feature flag per city with instant rollback.

Support tooling pulls the trip's event history: the quote snapshot with rate card version and surge, state transitions with timestamps, the raw GPS trace, any route changes the rider asked for, waiting time, and toll evidence. The system recomputes the fare from the snapshotted rules and compares it with what was charged. If the driver took an unnecessarily long route, as shown by comparing the actual path with the expected route, the fare is adjusted to the expected route. Rules allow auto-refunds for clear cases within limits. Refunds go through the ledger with idempotent references. Patterns of disputes against particular drivers feed quality reviews.

Vehicle type is a first-class attribute on the driver, the quote and the trip. The same pipeline is configured per product. Rate cards differ by product and city, including regulated fare structures where they apply. Routing profiles differ, since a two-wheeler can use lanes a sedan cannot, so ETAs come from profile-specific road weights. Matching filters candidates by product, and may offer a rider several products if they choose 'any'. Safety rules can vary too, such as helmet reminders for bikes. Regulations about which products can operate in a city are enforced through feature flags per city, so compliance changes do not need a code release.

1. ADisabling the Book button for five seconds
2. BRate limiting the rider to one request per minute
3. CAsking the rider to confirm twice
4. DA client-generated idempotency key enforced with a unique constraint on the serverCorrect answer

Why: The server deduplicates on the idempotency key and returns the original trip. UI tricks and rate limits do not guarantee this against network retries.

1. Apayment is pre-authorised
2. Bthe driver taps Start, regardless of anything else
3. Cthe rider's OTP entered by the driver matches the trip's OTP and the trip is in the correct prior stateCorrect answer
4. Dthe GPS shows the driver moving

Why: Requiring both the OTP match and a valid state transition prevents fake starts and wrong-rider pickups.

1. ASending it through the normal analytics pipeline
2. BFire-and-forget UDP message
3. CClient-generated ID, multiple channels with retries until a durable server acknowledgement, and isolated capacityCorrect answer
4. DLogging it to the app's local storage only

Why: Durable persistence before acknowledgement, idempotent retries and a priority path together make loss very unlikely.

1. AH3 removes the need for a routing engine to calculate ETA
2. BHexagons line up exactly with city administrative boundaries
3. CHexagons give every neighbour a similar centre distance, making ring searches and surge zones more uniformCorrect answer
4. DHexagons compress GPS coordinates into fewer bytes than latitude and longitude

Why: All six neighbours of a hexagon are roughly equidistant, so k-ring searches and cell-level aggregates behave consistently, unlike squares with corner neighbours. It is still only a coarse filter; road ETA ranking is done separately.

1. ALet the faster mobile network win
2. BA conditional update that assigns the driver only if the trip is still unassignedCorrect answer
3. CAssign both and cancel one manually
4. DCache the acceptance in the driver app before sending it

Why: A compare-and-set or version-checked write makes assignment atomic, so exactly one accept succeeds and the other gets a clean 'already taken' response.

1. ATo let the client edit the fare locally
2. BSo the server can honour the exact price shown for a limited time and reject stale quotesCorrect answer
3. CTo enable caching of the map tiles
4. DTo avoid calling the routing engine at drop

Why: The server stores the quote, and booking must reference a valid, unexpired quote ID. That binds the price shown to the rules applied.

1. ACompressing GPS traces
2. BChoosing the payment gateway
3. CFaster full-text search
4. DOptimistic concurrency control and detecting stale or duplicate eventsCorrect answer

Why: Conditional writes on the version stop two lost updates from racing. Downstream consumers can also use it to drop old or duplicate events.

1. AIt keeps each driver's pings in order within one partitionCorrect answer
2. BIt encrypts the pings
3. CIt reduces the size of each message
4. DIt guarantees global ordering of all pings

Why: Kafka only orders messages within a partition. Keying by driver ID keeps each driver's updates in sequence.

1. AAsk drivers to type in their ETA
2. BCompute ETA for every driver in the city
3. CPrefilter nearby drivers by H3 rings, then run a one-to-many ETA query on a small setCorrect answer
4. DUse straight-line distance only

Why: A cheap spatial prefilter narrows the candidates, so the expensive routing matrix runs on only a handful of drivers.

1. AOrdered delivery across all trips globally
2. BExactly-once with distributed transactions
3. CBest effort, since each update carries absolute position and timestampCorrect answer
4. DUpdates must be stored before being displayed

Why: A missed position is replaced by the next one. Strong guarantees would add cost and latency without helping the rider.

1. Athe snapshotted quote rules plus whitelisted adjustments such as tolls, waiting and rider-requested route changesCorrect answer
2. Bwhatever the driver enters
3. Cthe cheapest fare among competitors
4. Dthe live surge at drop time

Why: Using the snapshotted rules honours the agreed quote. Only defined adjustments with evidence may change the amount.

1. AIt is not recorded
2. BAs a debit on the driver's ledger, which may go negative and be netted against future earningsCorrect answer
3. CAs a charge on the rider's card
4. DAs a refund to the rider

Why: The driver already holds the cash, so the platform's share becomes a dues entry on the driver's ledger.

1. AMark it failed and charge again immediately
2. BKeep it pending, rely on webhooks plus status polling, and reconcile before any retryCorrect answer
3. CMark the trip cancelled
4. DAsk the driver to collect cash as well

Why: UPI results can arrive late. Charging again risks a double debit, so you confirm the status first.

1. APublish to Kafka first, then update the database
2. BTwo-phase commit across mobile clients
3. CWrite to the database, then publish to Kafka in a separate call
4. DTransactional outbox with a relay or change-data-captureCorrect answer

Why: The event row commits atomically with the state change and is reliably relayed afterwards.

1. AShow numbers only after trip start
2. BProxy or masked numbers and in-app calling, disabled shortly after the tripCorrect answer
3. CEncrypt numbers on screen
4. DShow only the last four digits but allow direct dialling

Why: Masking prevents either party from learning the real number. Cutting the link after the trip limits misuse.

1. ATo confirm the right rider is in the right vehicle before the trip startsCorrect answer
2. BTo calculate the waiting-time charge
3. CTo verify the rider's phone number at signup
4. DTo authorise the UPI payment

Why: The rider shares the OTP only with the driver who arrives, so the trip starts only when the correct rider and driver have met, preventing wrong pickups and fake trip starts.

1. AObject storage with daily partitions
2. BA blockchain ledger
3. CA data warehouse queried hourly
4. DAn in-memory geo index with TTL on entriesCorrect answer

Why: Matching needs fast reads and writes of fresh positions, and TTL removes silent drivers. Batch and archive stores are far too slow for this.

1. AIt removes surge pricing
2. BIt removes the need for an ETA service
3. CIt enables a better global assignment that lowers total pickup timeCorrect answer
4. DIt guarantees zero cancellations

Why: Solving many requests together avoids greedy choices that leave other riders with long pickups. The cost is a small added delay.

1. AExpire the offer server-side, release the reservation and offer the next ranked driverCorrect answer
2. BCancel the rider's trip immediately
3. CKeep waiting until the driver responds
4. DAssign the trip to the driver anyway

Why: A server-side timeout keeps the flow moving and frees the driver. The trip cascades to the next candidate.

1. ALook up the driver's gateway in a connection registry and route the message there, with push notification as fallbackCorrect answer
2. BWait for the driver to poll every minute
3. CSend an SMS only
4. DBroadcast to every gateway node and hope one owns it

Why: A connection registry maps each driver to the gateway holding their socket. Push covers the case where that connection is down.

1. A911
2. B112Correct answer
3. C999
4. D100 only

Why: India's Emergency Response Support System uses 112 as the integrated emergency number.

1. AIt avoids the need for idempotency
2. BIt removes the need for taxes
3. CIt is faster than any other storage
4. DIt gives an auditable trail where every movement balances, which makes reconciliation and correction safeCorrect answer

Why: Entries are never mutated and debits always match credits. Errors are fixed with compensating entries and are easy to trace.

1. AStateless and non-idempotent
2. BIdempotent, for example by tracking the last processed version per tripCorrect answer
3. CSingle-threaded globally
4. DRunning on the same host as the producer

Why: Duplicates will happen. Idempotent handling makes reprocessing harmless.

1. AApp version
2. BRider's first name
3. CCity or region, with large cities split further by cell rangesCorrect answer
4. DPayment method

Why: Matching and surge are local. Sharding by geography gives locality and isolates failures.

1. AIt is not needed after failover
2. BFrom last night's backup
3. CRebuilt from fresh driver pings within seconds, since it is soft stateCorrect answer
4. DManually by operations staff

Why: Locations are ephemeral and refreshed continuously, so the index can be repopulated quickly.

1. ALarger timeouts
2. BA single writer per city shard enforced by leases or fencing tokensCorrect answer
3. CClient-side retries
4. DTurning off surge

Why: Fencing ensures only the current lease holder's writes are accepted, avoiding split-brain double assignment.

1. ADigital Personal Data Protection Act 2023Correct answer
2. BMotor Vehicles Act 1988
3. CPayment and Settlement Systems Act 2007
4. DInformation Technology Act 2000 only, with no newer law

Why: The DPDP Act 2023 governs processing of digital personal data, including notice, consent and user rights.

1. APhone battery below 20%
2. BDriving at night
3. CSlow speeds in traffic
4. DImpossible jumps or speeds between consecutive pingsCorrect answer

Why: Physically implausible movement is a classic spoofing indicator. The others are normal conditions.

1. ARegulators forbid experiments
2. BThey are too cheap
3. CRiders and drivers share a supply pool, so groups interfere with each otherCorrect answer
4. DMatching has no measurable metrics

Why: Network effects leak between treatment and control. Switchback or geographic randomisation reduces this bias.

1. ABuffer GPS points locally, keep the trip active, and upload them in a batch on reconnectCorrect answer
2. BCharge the rider the maximum fare
3. CSwitch the trip to cash automatically
4. DAuto-cancel the trip after 30 seconds

Why: Offline buffering preserves the path for a fair fare and avoids disrupting a trip that is still in progress.

1. ALink requiring the viewer to log in as the rider
2. BPermanent link exposing the rider's full ride history
3. CTokenised, read-only link to the live trip that expires when the trip endsCorrect answer
4. DLink that includes the driver's real phone number

Why: Limiting the link's scope and lifetime gives safety visibility without leaking extra personal data.

1. AIt moves the pin to a reachable spot such as a road edge or gate, reducing calls and delaysCorrect answer
2. BIt reduces surge
3. CIt removes the need for OTP
4. DIt hides the rider's location from the driver

Why: GPS error and bad pins cause confusion. Snapping to accessible points speeds up pickups.

1. AThe rider is banned
2. BThe driver is fined
3. CFull fare is charged
4. DNo cancellation fee is chargedCorrect answer

Why: The grace window exists so riders can change their mind quickly without penalty.