Azure Architecture Guide

CH20-01: How to Use the Service Guide

Goal

This chapter is a compact Azure service guide, but it is not trying to replace Microsoft Learn. Product documentation tells you every feature, limit, API, and configuration option. This chapter has a different job: it helps you remember the architectural responsibility each service usually owns and the trade-offs that matter when you choose it.

The durable idea is:

Start from the architecture responsibility, then use service names to choose and explain a design.

The Short Version

A service name is useful only after you know the job you need done.

Use this chapter like a decision aid:

  • Start with the architecture concern.

  • Name the responsibility.

  • Identify Azure service options.

  • Compare trade-offs.

  • Explain the decision in plain language.

The pattern looks like this:

Architecture concern
  -> Responsibility
  -> Azure service options
  -> Trade-offs
  -> Decision explanation

If you start with service names, every question sounds like a product quiz. If you start with responsibility, service names become easier to remember because they sit inside a design reason.

How to Read Each Service Entry

Most entries in this chapter use the same compact shape:

Entry PartWhat It Helps You Decide
PurposeWhat architectural job the service usually performs.
Use WhenThe conditions where the service is a natural fit.
Avoid WhenSituations where another service or pattern may fit better.
Architecture PatternsCommon designs where the service appears.
Cloud ComparisonA vocabulary bridge for AWS or GCP users, when useful.
Decision PromptThe question to ask before selecting the service.

You do not have to memorize every service entry. Try to remember the responsibility and the decision prompt. The exact feature details can come from documentation when you implement.

Example: Event Grid Versus Service Bus

Suppose someone asks whether to use Azure Event Grid or Azure Service Bus.

A service-name answer says:

Use Event Grid for events and Service Bus for messages.

That is a start, but it is thin.

A responsibility answer says:

If the workload needs to notify subscribers that something happened, Event Grid is a good fit because it routes event notifications. If the workload needs durable work that must be stored until a consumer processes it, Service Bus is a better fit because it provides queues and topics for reliable messaging.

That answer is stronger because it names the failure behavior. Event Grid is not a durable work queue. Service Bus is not just a notification router. The services can even appear together: Event Grid can notify that something happened, while Service Bus protects a command or work item that must complete.

Cloud Comparisons Are Vocabulary Bridges

Readers coming from AWS or GCP often ask, "What is the equivalent?" That question is useful for orientation, but it is not enough for design.

For example, an AWS user may compare Azure Event Grid with Amazon EventBridge, or Azure Service Bus with Amazon SQS and SNS concepts. A GCP user may compare similar responsibilities with Eventarc or Pub/Sub. Those mappings help translation, but the real design question is still about responsibility, durability, routing, ordering, scale, ownership, and operations.

The same rule applies across this chapter:

Service names help you translate; boundaries help you design.

Common Mistakes

  • Memorizing service names without knowing the responsibility.

  • Treating cloud-service equivalence as a complete design answer.

  • Choosing by popularity instead of workload shape.

  • Ignoring ownership, failure behavior, security, monitoring, and cost.

  • Giving a one-word answer such as "AKS," "Cosmos DB," or "Event Grid" without explaining the trade-off.

If Someone Asks You

How should I use an Azure service reference when designing architecture?

A good answer is:

Use the service reference as a decision aid. Start with the architecture concern, name the responsibility, compare Azure service options, explain the trade-off, and include an operational note. Service names are useful, but the design answer should explain why the service fits and what responsibility the team accepts by choosing it.

What You Should Remember

Reference chapters are useful when they help you explain choices, not just recognize names.

Questions to Check Understanding

  1. Why should service selection start from responsibility?

  2. What does a good service entry include?

  3. Why are cloud comparisons incomplete by themselves?