Recipes/Mobility/stateful
durable operation2–3 hr5 stages8 code languages

Operating journey: A pickup flow that survives the real world

Shorter pickup times with fewer calls, cancellations, and unsafe rendezvous points.

The real-world moment

At a busy railway station, a rider searches for the station name but the legal vehicle pickup point is 420 metres away. The marketplace must suggest a safe entrance, match a driver by road ETA rather than straight-line distance, guide both parties, and preserve a reviewable record if either disputes arrival.

Make ownership visible before code.

Operate the full lifecycle with versioned state, hostile-path recovery, audit, and release evidence.

Application state
stateful
Planning calls
0
Credentials accepted
No
Write authority
None
01
Trip marketplace

Bias search to the rider viewport

Owns request, fare, rider/driver identities, eligibility, assignment, cancellation, safety state, and settlement.

Ride request ↔ accepted pickup/drop Mappls Pins and selection revisions

GETAutoSuggest API/api/places/search/jsonThis is a supporting operation from the selected product stack, not proof of an exact provider contract for this stage. Resolve the stage through its product source or adapter boundary before live implementation.

Record stage 1 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Search resolves the building centre

Present signed pickup zones/entrances as candidates and require explicit rider confirmation before matching.

02
Pickup intent

Confirm a precise pickup pin and landmark

Autosuggest and map confirmation resolve human text and viewport context to a precise Mappls Pin with entrance/landmark explanation.

Driver candidate ↔ capability, availability, position freshness, matrix ETA

GETGeocode API/api/places/geocodeThis is a supporting operation from the selected product stack, not proof of an exact provider contract for this stage. Resolve the stage through its product source or adapter boundary before live implementation.

Record stage 2 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Driver location is stale

Exclude it from ETA ranking, show marketplace capacity honestly, and request fresh evidence rather than extrapolating indefinitely.

03
ETA matching

Match with network-aware ETA

A bounded matrix ranks eligible fresh driver positions; marketplace policy adds workload, vehicle, safety, and deterministic tie-breaks.

Record stage 3 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Rider and driver disagree on arrival

Retain both event streams, accuracy, call/support actions, and apply a versioned human-review policy.

04
Approach journey

Track approach and reroute

Route revisions and event-time vehicle observations derive progress, rerouting, pickup-zone entry, and freshness.

Record stage 4 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Search resolves the building centre

Present signed pickup zones/entrances as candidates and require explicit rider confirmation before matching.

05
Shared rendezvous experience

Detect arrival and close the trip

Rider and driver receive the same stable pickup identity with role-appropriate directions and a support-visible discrepancy trail.

Ride request ↔ accepted pickup/drop Mappls Pins and selection revisions

GETGets the list of all the nearby devices./devices/nearbyThis normalized operation matches the stage intent and remains subject to its source, lifecycle, authentication, entitlement, host, and regional gates.

Record stage 5 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Driver location is stale

Exclude it from ETA ranking, show marketplace capacity honestly, and request fresh evidence rather than extrapolating indefinitely.

Edit once. Generate eight trusted-runtime implementations.

The recipe starts from the normalized GET /{REST_KEY}/still_image contract. Execute six deterministic fixture outcomes before an issued account is involved.

Local request composerCode stays local · fixtures are explicit
GETRequest inputs
6 editable · 1 protected
Generated in eight languages
Environment-backed credentials
GEThttps://apis.mapmyindia.com/advancedmaps/v1/${MAPPLS_REST_KEY}/still_image?center=28.5959394%2C77.2255611&zoom=15&size=400x400&ssf=1&markers=28.5959394%2C77.2255611&markers_icon=https%3A%2F%2Fimg.icons8.com%2Fmaterial-outlined%2F96%2F000000%2Ftruck.png
Credential-free sandboxExecute this contract without a provider call
How fixtures work
Generated from your inputs
curl --request GET \
  --url "https://apis.mapmyindia.com/advancedmaps/v1/${MAPPLS_REST_KEY}/still_image?center=28.5959394%2C77.2255611&zoom=15&size=400x400&ssf=1&markers=28.5959394%2C77.2255611&markers_icon=https%3A%2F%2Fimg.icons8.com%2Fmaterial-outlined%2F96%2F000000%2Ftruck.png" \
  --header "Accept: application/json"

Credential-safe by constructionSet MAPPLS_REST_KEY only in your trusted runtime. Code generation stays local. Sandbox execution sends only bounded fixture inputs to this developer platform and never reads a credential or calls Mappls.

Break the journey before customers do.

These controls are required at this operating depth; deeper recipes add durable truth rather than merely more API calls.

Idempotent commandsOptimistic aggregate versionsEvent and receipt timeTransactional outboxUnknown-outcome reconciliationIndependent human decisionsRestart recoveryImmutable audit evidence

Definition of done

Every aggregate has an invariant, expected version, stable command identity, and attributable actor.

Duplicate, late, reordered, invalid, stale, timed-out, and restarted execution preserve one durable truth.

Unknown provider outcomes reconcile by original identity before replay or compensation.

Terminal decisions, human review, audit, outbox delivery, privacy, retention, and rollback remain independently evidenced.

Contracts, tutorials, and journeys stay linked.

Contract set

GETStill Map Image API/{REST_KEY}/still_imageGETNearby API/api/places/nearby/jsonGETRouting API/{REST_KEY}/{resources}/{profile}/{geopositions}GETGets the list of all the nearby devices./devices/nearbyGETElevation API/{REST_KEY}/elevationGETAutoSuggest API/api/places/search/jsonGETRouting API with driving profile/{REST_KEY}/{resources}/driving/{geopositions}GETGets the live data of devices./devicePOSTTraveled Route Image API/{REST_KEY}/still_image_polylineGETGeocode API/api/places/geocodeGETRouting API with trucking profile/{REST_KEY}/{resources}/trucking/{geopositions}GETGets the historical location events of a device./devices/{deviceId}/events

Durable state machines

statefulConnected fleet trip6 states · 7 transitionsstatefulFleet geofence exception6 states · 5 transitionsstatefulCoordinated incident response7 states · 8 transitionshybridRecoverable navigation session6 states · 6 transitionshybridDurable multi-stop itinerary6 states · 9 transitionsstatefulConsented address verification9 states · 11 transitionshybridiOS direction planning and navigation handoff8 states · 8 transitionshybridiOS geofence draft and publication boundary6 states · 6 transitions

Care Transfer Desk

Confirm the correct receiving entrance, assign eligible transport, preserve courier custody, review condition exceptions, and reconcile receiver acceptance without retaining patient or clinical data.

Source-grounded, not authority-granting

This recipe composes source-derived contracts, application architecture, fixtures, and maintained learning evidence. It does not prove package availability, provider payload shape, account entitlement, regional behavior, production compatibility, or release approval.