You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few months back the request lifecycle looked something like this:
User sends request to routing layer.
Routing layer forwards the request to the server.
Server responds to routing.
Routing responds to user.
We concluded that this was bad because this meant that the (potentially large) value now made two hops: Server to routing and routing to user. The simple solution at the time was to make the routing layer simply respond with the addresses of the correct server and have the user communicate directly with the server. The result was a request lifecycle that looks like this:
User sends a key to the routing layer.
The routing layer responds with the addresses of the set of servers responsible for this key.
The user caches these addresses and sends the request directly to the server.
The server responds.
The user relies on its cache for future requests until a server receives a message for a key it's not responsible for. The server then tells the user to invalidate its cache for that key and return to step 1.
However, we’ve since changed the architecture of the user & routing components to make them asynchronous. When a user sends a request, it includes it’s IP address in the request so that the routing layer knows where to respond to, because it might have to make a request to determine the correct replication factor for the key. In light of that change, we should change the request pattern:
User sends request to routing layer.
Routing layer forwards request along to one of the correct servers.
Server responds directly to user.
Pros:
This reduces the maximum number of roundtrips for a request from 4 to 3.
Forces the routing layer to be invoked on every single request. i.e., the minimum number of requests goes from 2 to 3. Whether this is a net negative or positive depends on the workload.
A few months back the request lifecycle looked something like this:
We concluded that this was bad because this meant that the (potentially large) value now made two hops: Server to routing and routing to user. The simple solution at the time was to make the routing layer simply respond with the addresses of the correct server and have the user communicate directly with the server. The result was a request lifecycle that looks like this:
However, we’ve since changed the architecture of the user & routing components to make them asynchronous. When a user sends a request, it includes it’s IP address in the request so that the routing layer knows where to respond to, because it might have to make a request to determine the correct replication factor for the key. In light of that change, we should change the request pattern:
Pros:
Cons:
cc @cw75
The text was updated successfully, but these errors were encountered: