Services/F1/Server/Architecture

Big Picture

• The Post office Front server (PF) receives a send request.
• The request is pushed into a queue
• A worker (W) picks the job and push the result into a key/value storage
• the client grabs back the result via the Receiver Front server (RF)

Details

1. PF checks the status of a service by looking at the Services Status DB. Each service has a (GR / BR) ratio stored in that DB. GR = Number of good responses. BR = Number of bad responses. What are "Good" and "Bad" responses is to the workers discretion.

Given a threshold, PF can decide to return a 503 immediately, together with a Retry-After header.

2. PF creates a unique Session ID for the transaction and stores it into the Session DB.

3. PF push the work to be done, together with the session id, into the right queue. It then return a 202 code to the client.

4. A worker picks the job and do it. Once it gets the result back, it select a Result DB server by using a simple modulo-based shard algorithm. It pushes the result into the select Result DB.

5. The worker updates the Session DB by writing there the Result Server ID associated to the Session ID.

6. The worker updates the Service status DB.

7. When the user ask for the result via RF, RF looks in the Session DB what is the Response DB that has the stored result.

8. The RF then pick the result and returns it.

Databases

The Session DB and Services Status DB are key/value stores global to the cluster and replicated in several places. They can be eventually consistent.

The Result DB is a key/value store local to a single server. It holds the result for a specific transaction.

The queues are providing a Publisher/Subscriber pattern, where each worker picks jobs to be executed on a specific service.

Failure Scenarios

XXX

Security

XXX explains the level of security of each piece

OAuth Dance

XXX