Examkin

Question

Difficulty: HardPerform Container and Item Operations in Azure Cosmos DB using SDK

You are developing a multiplayer gaming platform that stores player session data in Azure Cosmos DB using the SQL API and the .NET SDK v3. The Cosmos DB account is configured with Session consistency. The platform consists of two independent microservices running on separate server instances, each initializing its own CosmosClient instance.

Microservice A writes a new session document to the database. Immediately after, Microservice B must read that same session document to validate a lobby entry request. You must ensure that Microservice B reads the latest session state (read-your-writes guarantee) while maintaining the lowest possible read latency and avoiding hot partition issues under high write volume.

Which code segment should you implement to satisfy these requirements?

  1. Initialize containers with partition key path "/userId".

    // Microservice A:
    PlayerSession session = new PlayerSession { Id = "session_987", UserId = "user_123", IsActive = true };
    ItemResponse<PlayerSession> writeResponse = await containerA.CreateItemAsync<PlayerSession>(
    session,
    new PartitionKey(session.UserId)
    );
    string token = writeResponse.Headers.Session;

    // Microservice B:
    ItemResponse<PlayerSession> readResponse = await containerB.ReadItemAsync<PlayerSession>(
    session.Id,
    new PartitionKey(session.UserId),
    new ItemRequestOptions { SessionToken = token }
    );    Answer
  2. B
    Initialize containers with partition key path "/isActive".

    // Microservice A:
    PlayerSession session = new PlayerSession { Id = "session_987", UserId = "user_123", IsActive = true };
    ItemResponse<PlayerSession> writeResponse = await containerA.CreateItemAsync<PlayerSession>(
    session,
    new PartitionKey(session.IsActive.ToString().ToLower())
    );
    string token = writeResponse.Headers.Session;

    // Microservice B:
    ItemResponse<PlayerSession> readResponse = await containerB.ReadItemAsync<PlayerSession>(
    session.Id,
    new PartitionKey(session.IsActive.ToString().ToLower()),
    new ItemRequestOptions { SessionToken = token }
    );
  3. C
    Initialize containers with partition key path "/userId".

    // Microservice A:
    PlayerSession session = new PlayerSession { Id = "session_987", UserId = "user_123", IsActive = true };
    await containerA.CreateItemAsync<PlayerSession>(
    session,
    new PartitionKey(session.UserId)
    );

    // Microservice B:
    ItemResponse<PlayerSession> readResponse = await containerB.ReadItemAsync<PlayerSession>(
    session.Id,
    new PartitionKey(session.UserId)
    );
  4. D
    Initialize containers with partition key path "/userId".

    // Microservice A:
    PlayerSession session = new PlayerSession { Id = "session_987", UserId = "user_123", IsActive = true };
    await containerA.CreateItemAsync<PlayerSession>(
    session,
    new PartitionKey(session.UserId)
    );

    // Microservice B:
    ItemResponse<PlayerSession> readResponse = await containerB.ReadItemAsync<PlayerSession>(
    session.Id,
    new PartitionKey(session.UserId),
    new ItemRequestOptions { SessionToken = session.UserId }
    );

Answer

The correct implementation configures the container with a high-cardinality partition key path of "/userId", retrieves the Session Token from the write response headers via Headers.Session in the writing client, and explicitly applies it using ItemRequestOptions.SessionToken on the reading client.
The correct answer provides a high-cardinality partition key path ('/userId') which guarantees a uniform distribution of throughput and storage across partitions. To achieve read-your-writes consistency across two distinct CosmosClient instances, the application must capture the session token from the write operation's response headers (Headers.Session) and provide it to the subsequent read operation using ItemRequestOptions.

Step-by-Step Solution

1
Select a high-cardinality partition key.
The path "/userId" is chosen instead of low-cardinality attributes like "/isActive" to distribute write load evenly.
Choosing a poor partition key with low cardinality results in hot logical partitions and eventual rate-limiting.
2
Retrieve the session token after the write operation.
Access the session token string via writeResponse.Headers.Session.
Cosmos DB Session consistency is scoped to the client instance. Since the microservices run on separate client instances, the token must be shared externally.
3
Inject the session token into the read request configuration.
Populate the SessionToken property in the ItemRequestOptions object when calling ReadItemAsync.
This instructs the second client to read from a replica that has caught up at least to the version indicated by the session token.

Key Concept

Explicitly passing Session Tokens across independent CosmosClient instances to guarantee read-your-writes consistency while maintaining high-cardinality partition structures.
Estimated Time:2m 30s
Rate this question

Topics

Perform Container and Item Operations in Azure Cosmos DB using SDK

More questions from this topic