This document details the software implementation of svc-pricing (the "pricing module").
The pricing module is responsible for computing the cost for given flight trips.
Note: This module is intended to be used by other Arrow micro-services via gRPC.
This document is under development as Arrow operates on a pre-revenue and pre-commercial stage. Pricing logics may evolve as per business needs, which may result in architectural/implementation changes to the pricing module.
| Attribute | Description |
|---|---|
| Maintainer(s) | Services Team |
| Stuckee | @GoodluckH |
| Status | Development |
| Document | Description |
|---|---|
| --- | --- |
| High-Level Concept of Operations (CONOPS) | Overview of Arrow microservices. |
| High-Level Interface Control Document (ICD) | Interfaces and frameworks common to all Arrow microservices. |
Requirements - svc-pricing |
Requirements and user stories for this microservice. |
Concept of Operations - svc-pricing |
Defines the motivation and duties of this microservice. |
Interface Control Document (ICD) - svc-pricing |
Defines the inputs and outputs of this microservice. |
| Pricing Model | Unit economics and pricing mechanism of flights. The core logic of svc-pricing is largely derived from the pricing model. |
| Uber Elevate White Paper | Uber's research on UAM operations. Certain economic assumptions are referenced by Arrow's pricing model. |
| Attribute | Applies | Explanation |
|---|---|---|
| Safety Critical | No | Pricing is business critical but has no direct impact to the operational safety. |
| Realtime | No | Currently, the price of a trip is computed and supplied to customers as an upfront quote. The price is intended to be final and contractually effective upon customers' booking confirmation. The price computed by svc-pricing will become a persistent state associated with a particular flight.Dynamic pricing can be in realtime, but it will be the responsibility of other modules. |
This module does not require user-side initialization.
The main function in /server/src/main.rs will simply spin up the server at the provided port.
The only environment variables are the port numbers used to spin up the server.
For the pricing server, DOCKER_PORT_GRPC is the port number where the server lives. If not provided, 50051 will be used as a fallback port.
For the client, HOST_PORT_GRPC is needed to connect to the pricing server. This env var should be the server's port. If not provided, 50051 will be used as a fallback port. In most cases, one may assume HOST_PORT_GRPC to have the same value as DOCKER_PORT_GRPC.
Does not apply.
This module is stateless and is expected to be called on-demand as a function by other modules through gRPC.
Does not apply.
See the ICD for this microservice.