Skip to content

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

Closed

Description

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions