Design patterns are where good data modeling lives or dies. In a NoSQL database like Azure Cosmos DB, the difference between a schema that scales to millions of operations per second and one that fights you at every turn usually comes down to a handful of well‑understood patterns: how you partition, how you version, how you fan out work, how you keep concurrent writers from stepping on each other.That's exactly what the Azure Cosmos DB Design Patterns repo is for. It's a growing, hands‑on collection of small, focused samples — each one isolates a single pattern, explains why it matters, and lets you run it yourself and watch it work.We recently gave the repo a big update. Here's what's new.The core idea: patterns you can see, not just read aboutMost pattern catalogs are prose and diagrams. This repo takes a different stance: every pattern ships as a runnable sample with an interactive web front end. You don't just read that a distributed lock uses fencing tokens — you start a few workers, watch them contend for the lock in real time, crash the holder, and see the lease auto‑release. The picture is the lesson.Three principles guide the whole collection: Emulator‑first. Every sample runs entirely on your machine against the Azure Cosmos DB Linux (vNext) emulator. No Azure subscription, no account, no keys — just docker compose up -d and dotnet run. Zero setup is the default path. Interactive web UX for every pattern. A small Blazor front end turns each abstract pattern into something you can click, break, and reason about — with "why it matters" talking points built right into the page. Secure and optional cloud. When you do want to see it in Azure, each sample includes a one‑command Azure Developer CLI (azd) template that provisions a keyless (Microsoft Entra ID + managed identity) deployment — no secrets stored anywhere.Five brand‑new patterns1. Vector SearchSemantic search over your operational data using Azure Cosmos DB's built‑in vector indexing and the VectorDistance() function — the storage‑and‑retrieval foundation of RAG. What makes this sample special: it embeds text with a small local model, so there's no API key and no external service. That quietly solves a real pain point — you can build and CI/CD an app that uses embeddings without pre‑deploying a foundation model or baking keys into GitHub secrets.2. Loop‑Safe Change FeedA classic trap: you use the change feed to derive a value and write it back onto the same document — and your write re‑triggers the feed, which writes again… forever. This sample shows the standard fix: store a hash of the source and skip any change whose hash is unchanged (the echo of your own write). One real edit produces exactly one enrichment and one skipped echo — the loop is bounded instead of runaway.Each document gets an identicon derived from its text. The enrichment writes and skipped echoes counters climb together — one of each per edit — which is the loop‑safety guarantee made visible.3. Hierarchical Partition KeyWhen a single partition key isn't enough, hierarchical (sub)partitioning lets you distribute data across multiple key levels while keeping related items co‑located. The sample models a realistic multi‑tenant shape and shows the cost and performance impact of getting your partition strategy right.4. Transactional OutboxPlacing an order should both change state and publish an event other systems consume — reliably. Doing those as two separate writes is a dual‑write, and a crash in between loses the event. This sample writes the order and the event in a single atomic TransactionalBatch, then relays the event with the change feed — so it can never be lost, even if the app dies the instant after commit. There's a crash‑toggle playground that lets you watch the naive version lose events while the outbox never does.5. Patch API (Partial Document Update)Updating one field usually means a read‑modify‑write: read the whole document, change a field, write it all back. The Patch API sends only the operation instead — cheaper, lower latency, and no lost updates when different services update different fields. The sample makes the trade‑offs concrete with a three‑way concurrency race, measured on the emulator:ApproachResultConflictsRURead‑modify‑write, no ETag❌ an update is lost04Read‑modify‑write + ETag✅ correct, after re‑read + retry16Patch✅ correct02The honest punchline: an ETag makes read‑modify‑write correct, but because it guards the whole document, two services touching different fields still collide with a needless 412 and pay to retry. Patch just… doesn't.A pattern in motion: the reworked Distributed LockDistributed Lock isn't new to the repo, but it got a full rework and a live web playground this cycle — and it's the best single illustration of the "see it work" philosophy. Every acquire, renewal, and release you see is a real operation against Azure Cosmos DB.Only one worker holds the lock at a time (mutual exclusion). The holder carries a fencing token; the protected resource accepts only the current holder's token, so a stale writer's updates are rejected. Crash the holder and the lease auto‑releases via TTL — no deadlock.Drag a worker's Work longer than the lock TTL and watch auto‑renew keep the lease alive. Turn auto‑renew off and watch the lease expire mid‑work, another worker take over, and the stale holder's writes get rejected by the fencing token. It's a whole distributed‑systems lecture you can run in a browser tab.Under the hood: quality that makes the samples trustworthyAlongside the new patterns, the repo got a foundation upgrade: .NET 10 across every sample. Emulator‑backed integration tests in CI — the test suite runs against the Cosmos DB Linux emulator on every pull request, with no secrets, so the patterns are verified to actually work. Keyless azd deployments for every sample — managed identity, local key auth disabled, nothing sensitive stored. Unified, streamlined docs — every sample's README now follows the same shape (get the code → configure → run locally → optionally deploy), linking back to a shared setup guide instead of repeating stale portal instructions.Try it in five minutesgit clone https://github.com/Azure-Samples/cosmos-db-design-patterns.gitcd cosmos-db-design-patternsdocker compose up -d # start the local emulatorcd loop-safe-change-feed/source/Websitedotnet run # open the URL it printsPick any pattern folder, run its web front end, and start clicking. Whether you're choosing a partition strategy, wiring up reliable eventing, or reaching for vector search, there's now a small, honest, runnable example waiting to show you how it behaves — before you build it for real.👉 Explore the Azure Cosmos DB Design Patterns repo and let us know which pattern you'd like to see next by adding ideas to our GitHub Issues.