Contact person: Resolve Taxi-App Issues - An experienced expert is sought.

Phone:Show

Email:Show

Location: Antalya, Turkey

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"There are some issues in our taxi-hailing app.

What is issues?
Problems with driver re-connect, disconnection handling, and visibility on the map post-ride.

Tech Stack: GCP (Cloud Run, Pub/Sub, Firestore), Node.js, Redis, Flutter frontend.

Architecture: Event-driven, serverless, gRPC streaming between drivers and backend.

We don't want a man-hour estimate. We want a fixed price.
A expert, views the code, identifies the error, fixes it, and gets paid.

Those who do not have applications prepared with location information, maps, etc. modules in their references should not apply.

The system architecture is shown in the attached image.

Detailed issues test videos are below links:

Test Video 1 ( Issue 1 )
[login to view URL]

Test Video 2 ( Issue 2 )
[login to view URL]


System analysis using the question-and-answer method:

1. Real-Time Driver State Management
How exactly are driver state transitions modeled today (available → on-ride → completed)? Is this versioned or atomic in any way?
Is Redis the source of truth, or is Firestore authoritative during race conditions?


Answer: Currently modeled linearly: available → on-ride → completed. These transitions are not versioned but rely on Redis atomic updates. However, Firestore is considered the authoritative source during race conditions.



2. gRPC & Disconnection Handling
What is the current behavior when a gRPC stream disconnects (driver app closed or network loss)? Do you have TTL, heartbeats, or reconnect logic?

Answer: If a gRPC stream disconnects (app closed or network issue), the system lacks robust TTL or heartbeat tracking. No reconnect logic is in place currently.



3. Map Display & Visibility Logic
What determines which drivers are shown on the passenger map? Is this Redis GEO-based filtering, or another method? What’s the trigger mechanism for pushing updated driver lists to the frontend?

Answer: Visibility is determined by Redis GEO queries (GEOADD + GEORADIUS). Updates are pushed to the frontend via manual triggers or event-based updates (Pub/Sub or Firestore listeners).


4. Pub/Sub & Backend Triggers
Are Pub/Sub events triggering Cloud Functions, Cloud Run services, or both?
Do you have any ordering guarantees in these events (e.g., message IDs, timestamps)?

Answer: Pub/Sub events trigger both Cloud Functions and Cloud Run services depending on the use case. No strict ordering guarantees exist — message timestamps help maintain sequence loosely.


5. Development & QA Environment
Is there a staging environment where we can safely test refactored stream/Redis logic before going live?
Can you provide access to current logs or monitoring dashboards (e.g., Stackdriver or similar)?

Answer: No, there is no stating environment. If the backend team sets up a staging environment and provides the necessary API endpoints, ports, and connection details, we can connect the mobile app to it accordingly. In that case, we can also generate an APK and share it for testing purposes.


6. Driver Stream Lifecycle:
Could you clarify how you’re currently managing the driver's stream lifecycle? What happens if a stream is interrupted, and how do you manage reconnection or recovery?

Answer: Driver streams are managed via gRPC/WebSocket. If a stream is interrupted, the driver may remain in Redis. Reconnection requires re-authentication; the previous state isn’t automatically restored.


7. Data Integrity Checks:
When a driver is added back to the pool, how do you ensure there’s no data corruption or out-of-sync states between Redis and Firestore?

Answer: Redis handles real-time location, while Firestore stores the authoritative driver state. There is no enforced synchronization check between them, and inconsistencies may occur." (client-provided description)