Here is a simplified breakdown of the patterns found in the Azure documentation, grouped by the "problems" they solve.

Communication & Connectivity

• Ambassador: Think of this as a "personal assistant" for your app that handles networking, security, and logging so the app doesn't have to.
• Anti-Corruption Layer: A "translator" between a modern app and a messy old system so the old system's "bad habits" don't infect the new one.
• Asynchronous Request-Reply: Instead of waiting on the phone for an answer, you leave a message, and they call you back when the job is done.
• Backends for Frontends: Creating a specific "mini-backend" for different devices (like one for mobile and one for web) so they only get the data they need.
• Gateway Aggregation: Instead of a customer calling 10 departments, they call one "Front Desk" that gathers all the info for them in one go.
• Gateway Offloading: Moving "heavy lifting" like security or SSL checks to a gateway so the main app can stay fast.
• Gateway Routing: A "traffic controller" at the entrance that sends requests to the right service based on where they need to go.
• Sidecar: Attaching a "helper tool" (like a sidecar on a motorcycle) to your app to handle things like monitoring without changing the app's code.

Reliability & Resilience

• Bulkhead: Like a ship with sealed sections—if one room floods (crashes), the whole ship stays afloat.
• Circuit Breaker: If a service is broken, stop trying to hit it for a while so it can recover, rather than making it worse.
• Compensating Transaction: If a long process fails halfway (like booking a flight but failing the hotel), this "undos" the flight booking automatically.
• Health Endpoint Monitoring: A "check-up" light that tells external tools if your app is still feeling okay or if it's sick.
• Leader Election: If you have 10 identical servers, they "vote" on one leader to be the boss so they don't do the same work twice.
• Retry: If a request fails because of a glitch, just try it again a few times before giving up.

Data Management & Speed

• Cache-Aside: Keeping a "cheat sheet" of common data in fast memory so you don't have to look it up in the slow database every time.
• CQRS: Separating the "writing" team from the "reading" team so they can both work faster without getting in each other's way.
• Event Sourcing: Instead of just saving the current status, you save every single "event" (change) that ever happened, like a bank ledger.
• Index Table: Like an index at the back of a book—it helps you find specific data in a giant database instantly.
• Materialized View: Creating a "pre-made summary" of complex data so you don't have to calculate it every time someone asks.
• Sharding: Cutting a massive database into smaller "shards" (chunks) so it's easier to manage and scale.
• Valet Key: Giving a user a "temporary pass" to upload a file directly to storage so your server doesn't have to do the heavy lifting.

Messaging & Coordination

• Choreography: Services talk to each other like dancers—they each know what to do when they see a specific "signal" without a central conductor.
• Claim Check: If a message is too big for the mail, you leave the "box" in storage and just send the "receipt" (the claim check) to the recipient.
• Competing Consumers: Having multiple workers pull from one "To-Do" list so they can get through the pile of work faster.
• Messaging Bridge: A "bridge" that allows two different messaging systems that don't speak the same language to talk to each other.
• Pipes and Filters: Breaking a complex task into a "pipeline" of simple steps (e.g., Step 1: Clean data, Step 2: Format data, Step 3: Save data).
• Priority Queue: An "emergency room" style line—urgent tasks jump to the front, while less important ones wait.
• Publisher/Subscriber: An "announcement system"—one service shouts news, and anyone "subscribed" hears it, but the sender doesn't care who is listening.
• Queue-Based Load Leveling: Using a "buffer" (queue) to catch a sudden flood of requests so your app doesn't crash from the pressure.
• Saga: Coordinating a sequence of local transactions across different services to make sure everything stays in sync.
• Sequential Convoy: Ensuring that a group of related messages are processed in the exact order they arrived.

Operational & Scaling

• Compute Resource Consolidation: Putting several small tasks onto one server to save money (like carpooling).
• Deployment Stamps: Making "cookie-cutter" copies of your entire app in different parts of the world to handle more users.
• External Configuration Store: Moving settings (like passwords or URLs) out of the code and into a central "vault" so you can change them without restarting the app.
• Federated Identity: Letting users log in using their Google or Microsoft account instead of making them create a new one for your app.
• Geode: Deploying your app in "nodes" all over the globe so the user always talks to the one closest to them.
• Quarantine: Putting a new or suspicious update in a "waiting room" to make sure it's safe before letting it into the main system.
• Rate Limiting: Setting a "speed limit" for how many requests a user can make to keep things fair for everyone.
• Static Content Hosting: Putting "fixed" things like images or HTML on a simple storage service instead of your expensive app server.
• Strangler Fig: Replacing an old system by slowly building new parts around it until the old one can be safely removed.
• Throttling: Slowing down or rejecting users if they are using too many resources, to protect the system from crashing.
• Scheduler Agent Supervisor: A "manager" that tracks a multi-step task and makes sure every step finishes correctly.