CRUD Operations in Cosmos DB

1. CRUD Operations in Cosmos DB

We've seen what Cosmos DB is and why its architecture is so powerful. Now, let's put it to work. How does Cipher Coffee actually Create, Read, Update, and Delete the data in its loyalty program?

2. Create

As with Blob Storage, the primary way to interact with Cosmos DB from an application is by using an SDK. Let's follow the journey of a loyalty member's data. Create: A new customer signs up. The application's code uses the SDK to create a new JSON document for them in the loyalty container.

3. Read

Read: The customer opens the Cipher Coffee app to check their points. The app uses the SDK to read their specific document by its unique ID.

4. Update

Update: The customer redeems 100 points for a free coffee. The app finds their document and updates the points value from 100 to 0. Note that while you can update most fields, the partition key field must not change during updates, it's immutable and defines where the document lives.

5. Delete

Delete: A user requests to close their account. A backend process uses the SDK to permanently delete their document from the container. This all seems straightforward, but global distribution adds a fascinating question...

6. Choosing Your Consistency

When Cipher Coffee updates a customer's points in London, how quickly does a user in the Tokyo app see that change? The answer is: it depends on the consistency level you choose. Cosmos DB offers a spectrum of five consistency levels, Strong, Bounded Staleness, Session, Consistent prefix and Eventual. Letting you balance data correctness against performance. Let's imagine we're updating a "Daily Special" menu item.

7. Strong

Strong: Every cafe in the world must show the exact same special. If London changes it, all other locations are blocked until they confirm the update. This gives perfect consistency but is the slowest. It's ideal for financial transactions where accuracy is everything.

8. Boundless staleness

Bounded Staleness: You can configure a tolerable "staleness." For example, other cafes might be no longer than 5 seconds or 10 updates behind London. This provides predictable and reliable reads.

9. Session

Session: This is the default and most popular level. Any changes you make are instantly readable by you within your application session. Other users might see the old data for a short time, but your own experience is always consistent. Perfect for shopping carts and most user-centric apps.

10. Consistent prefix

Consistent Prefix means you will always see changes in the order they were made, but you might not see all of them right away if updates are happening quickly. Think of it like watching a live sports match with a slight delay — you might see the plays in the correct sequence, but you may still be a few seconds behind the latest action. Example: If the real update is Latte, Mocha, Cappuccino, you might first see Latte, then jump straight to Cappuccino, skipping Mocha, but you will never see them out of order (e.g., Mocha, Latte).

11. Eventual

Eventual: The weakest level. All cafes will eventually get the update, but with no guarantee on timing or order. This offers the lowest latency and highest availability, making it great for non-critical data like counting 'likes' or retweets.

12. Fine tuning behavior

By choosing the right consistency level, you can fine-tune your app's behavior for your specific needs.

13. Let's practice!

Let's jump in and practice!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.