About the Auto Discovery service

This page provides an overview of the Auto Discovery service for Memorystore for Memcached. To learn how to access and connect to the Auto Discovery service, see Using the Auto Discovery Service.

The Auto Discovery service is a programmatic way for clients to automatically adapt to the addition and removal of node IP addresses that happens when you scale your Memcached instance.

If you don't use the Auto Discovery service, you must manually manage the node IP address list in your memcached client during scaling. Manually managing the node IP address list adds additional overhead because you must ensure that the clients are updated as the instance scales up and down. The Auto Discovery helps to automate this work for you.

You should use the Auto Discovery endpoint for its intended purpose, and not to run Memcached commands such as get, set, and delete.

Overview of Auto Discovery service architecture

Memorystore for Memcached exposes the Auto Discovery service using a discovery endpoint. The discovery endpoint is a dedicated IP address for your instance that returns a current list of nodes in your Memcached instance. Every Memorystore for Memcached instance has a unique discovery endpoint. Once the instance is created, the IP address of the discovery endpoint does not change.

To get the instance's Auto Discovery information, you query the discovery endpoint. The discovery endpoint returns the following information:

Field Description Datatype Example
Configuration version ID ID that increments for each node list change Integer 9
Node List Returns a list of current nodes and their IP addresses. String node1-ip|node1-ip|node1-port node2-ip|node2-ip|node2-port

Memorystore for Memcached directly exposes the discovery endpoint, however auto discovery must also be available in your client libraries. There are two ways to have auto discovery in your clients:

  1. Use a client library that supports auto discovery.

    • Golang memcached client fork.

  2. Manually add auto discovery logic to your client library.

Auto Discovery service behavior

The Auto Discovery service is eventually consistent. There can be a delay (on the order of seconds) while the Auto Discovery node list catches up to the current cluster configuration after a scaling operation.

Eventual consistency, in addition to the distributed nature of the service, can produce the following behavior for clients. The client logic should be designed to account for this behavior:

  • Same client on two separate queries to the Auto Discovery service can receive two different Auto Discovery responses from the service (while the service is inconsistent). However, one of the responses has a higher Configuration version ID which clients can use to handle the responses.

  • Two clients can receive two different Auto Discovery responses from the service (while the service is inconsistent), but they don't have a way to find which one is latest as clients don't talk to each other. While in this state, the instance can return cache misses. In this scenario, clients have to wait for the Auto Discovery service to become consistent.

What's next