What this prompt does
This prompt makes the AI a systems architect designing a ride-sharing service similar to [reference_platform] operating in [city_count] cities. It covers core flows, a geospatial matching service, a dynamic surge-pricing engine, trip tracking, payment and settlement, and reliability and safety. The matching step partitions each city into [grid_size] cells using S2 or geohash, indexes available drivers in [location_store], and cascades a request to the next driver after an [accept_timeout].
The structure works because real-time matching is a geospatial-plus-queue problem where small early decisions compound. Getting the grid partitioning and the acceptance-timeout cascade right prevents a painful rewrite once concurrency climbs toward [concurrent_rides]. Surge pricing keys off a live demand-to-supply ratio, applying a multiplier above [surge_threshold] and capping at [max_surge], with the fare estimate shown before the rider confirms. Trip tracking ingests GPS at [gps_frequency] through [message_queue] so [driver_count] location updates per second don't get dropped, stores the polyline in [trip_database] for later analysis, and flags anomalies like unexpected stops or route deviations for safety alerts.
When to use it
- You're scoping a real-time location and matching system before committing infrastructure
- You need geospatial partitioning and a driver-acceptance cascade designed correctly up front
- You want a dynamic pricing engine grounded in live supply and demand
- You're handling high-frequency GPS ingestion without data loss
- You need ETA calculation from
[maps_provider]and trip-anomaly detection wired into tracking - You want settlement, commissions, and safety features designed alongside matching
- You need to match a driver within
[match_time]across[city_count]cities
Example output
Expect an architecture document: the rider-to-driver flow, a geospatial matching design with [grid_size] partitioning and ranked candidate selection by distance, pickup time, and rating, a surge-pricing engine with the base-plus-distance-plus-duration fare formula and multiplier caps, a trip-tracking service streaming GPS through [realtime_protocol] with live ETA updates from [maps_provider], a payment and settlement flow with fare pre-authorization, final reconciliation, and the [commission_rate] cut, and a safety section covering trip sharing and an emergency SOS button. It's a reasoned design, not code.
Pro tips
- Tune
[grid_size]to city density; cells too large bloat candidate searches, too small and you miss nearby drivers across boundaries - Keep
[accept_timeout]short enough that riders aren't left waiting but long enough for drivers to react - Set
[surge_threshold]and[max_surge]deliberately — uncapped surge is both a UX and a regulatory problem - Buffer GPS through
[message_queue]before storage; writing[driver_count]updates per second straight to a database will not hold - Match
[gps_frequency]to your accuracy needs; more frequent updates mean smoother tracking but heavier ingestion - Always search adjacent cells, not just the rider's cell, or you'll miss the closest driver sitting one boundary over
