Confirmed users
927
edits
Services/F1/Server/Architecture: Difference between revisions
no edit summary
Tarek.ziade (talk | contribs) No edit summary |
Tarek.ziade (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
[[File:Eff-ouane-two.png]] | [[File:Eff-ouane-two.png]] | ||
= 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. | |||
= Persitency / Consistency = | |||
XXX | |||