Board Review: Caching responses in track 2 data-plane clients

[srnagar]

Contacts and Timeline

• Service team responsible for the client library: ADP
• Main contacts: @srnagar

About the Client Library

• Name of client library: General design guidelines for caching that applies to all track 2 data-plane clients

We want to discuss the design guidelines for creating a client that can potentially cache certain types of responses. In this review, we'd like to cover the following topics:

• Should the client be stateful and cache responses?
• If the client supports caching, should it be a separate client type?
• Return type for APIs that can return cached responses
• Cache eviction policy
• Max cache size

More details and various options are outlined in this gist - https://gist.github.com/srnagar/7ad722535ab2cb01a5160de551aab818

Example

Schema Registry service is a concrete example where the schema is immutable once created. So, if the client gets the schema from the service, it is safe to cache it on the client. The schema is used to deserialize every event from Event Hubs and making a service call to get the schema for every event received is not optimal.

[kyle-patterson]

Scheduled for 9/8

[tg-msft]

Recording[MS INTERNAL ONLY]

[srnagar]

No further action is required. Closing this issue.