-
Notifications
You must be signed in to change notification settings - Fork 156
Mission Control High level Architecture
Captain calls register_vehicle using thrift with its DAV UID. Receives back a channel id (that is unique to this vehicle).
Mission Control saves the vehicle details in the database and in Redis along with its channel id.
Calls from Mission Control to Captain are published to that channel id.
Captain subscribes to messages from Mission Control on that channel id.
All calls from Captain to Mission Control go through Thrift.
When there is a mission request from an app, Mission Control finds all vehicles in range from Redis and publishes a message to their individual channels. They respond via Thrift.
Write Thrift IDL and generate RPC interface from Captain to Mission Control in JavaScript. Create REST or GraphQL interface for same data for the app. Both should use common functions to get data but construct different responses.
Captain opens and closes RPC sockets to Mission Control on demand.
All data is written directly to PostgreSQL database.
Drone status including channel id is also written directly to Redis.
In a second stage, we could improve performance by not writing all drone status updates in real time to the database. We could use Firehose batched into S3 files for the status updates and batch insert them PostgreSQL (without channel id). Redis only holds the latest status. PostgreSQL contains full history.
All data except drone status is read from PostgreSQL database.
Current drone status is read from Redis.