This message was deleted.

The primary reason is to avoid the cost of cross-AZ traffic.

Thank you for quick reply @Felix GV! The motivation to decrease cross-AZ traffic is caused by cost factor and added latency (almost one ms for us-east-1 in AWS). Kyle did a good work measuring it.

I see, that's interesting... would be good to explore it further... My first intuition is that it probably does not make sense to add support for AZ-awareness in the thin client, as it seems to me it wouldn't be that thin anymore. However, it could definitely make sense to add this at the layer of the router, and in the fast-client as well...

@Felix GV well, I can't speak from financial or human resources perspective but technically, yes, we (LiveIntent) are interested in AZ-awareness/preference in Venice clients (at least, fast one). I also have no ready-to-go solution for AZ-awareness/locality. My idea for it was to assign a query cost for each AZ (or setting cost to 0 to one AZ and 0xffff for others by default). So both server and client should be aware about their "local" AZ and client should prefer "local" communications but not reject remote ones in emergent cases. What do you think about it?

Yeah it’s an interesting idea, for sure

I agree that adding the zone awareness would remove the "thin" part from the

thin-client

. That said, we can still start with it and gradually move to the fast one, assuming it gets the required characteristics.

You mean start with using the thin-client as is and eventually move to using the fast-client? Or start with developing this extra functionality within the thin-client?

thin -> fast 🙂

Got it, makes sense