BrainyBeeBrainyBee
ExploreBlogStart Studying
HomeDesigning Microsoft Azure Infrastructure Solutions (AZ-305)Quick Note — Recommend an Event-Driven Architecture
LO Quick Note864 words

Quick Note — Recommend an Event-Driven Architecture

AZ-305 › Unit 4: Design infrastructure solutions › Design an application architecture › Recommend an event-driven architecture

Quick Note — Recommend an Event-Driven Architecture

A bank's payments team migrates an aging batch reconciliation pipeline to "modern microservices". The first design is twelve services calling each other over HTTP — a service-oriented architecture in name only. Two months in, every change to one service breaks two others, latency creeps up as the call depth grows, and a single slow dependency takes down the whole chain. The architect proposes a structural redesign: each service publishes domain events to an event backbone, and downstream services subscribe to the events they care about. Two months later the team ships features independently, latency drops, and a slow service degrades only its own work — not the front door.…

Retrieval target

Objective
Recommend an Event-Driven Architecture
Mode
Closed-book recall
Target time
5 minutes
Escalation
Open the full lesson after a miss

Decision anchors

PromptCompact answer
Azure Event GridA push-based event-routing service for discrete state-change events. Sources publish events; Event Grid routes to subscribed handlers (Functions, Logic Apps, webhooks, Event Hubs). Native system topics for Azure services (Storage blob created, RG deployment complete, Resource modified, AKS health). Custom topics for app-generated events. At-least-once delivery, 24-h retry, DLQ to Blob.
Azure Event HubsA big-data streaming ingest service. Ingests millions of events/second; events sit in partitions (ordered, append-only logs) for 1–7 days (longer with Capture or Premium dedicated). Pull-based consumers (consumer groups). Use for telemetry firehose, app logs, IoT, click streams — anything where each event is small but volume is huge.
Event Grid system topic vs custom topicSystem topic — Azure-emitted events from a specific resource (Storage account 'BlobCreated', Subscription 'ResourceWriteSuccess', AKS, ACR, etc.). Auto-created when you subscribe. Custom topic — you create the topic, your apps publish events to it via SDK / REST. Subscribers can be any Event Grid handler. Use custom topics to publish your own domain events ('OrderPlaced', 'CustomerSignedUp').
Event Hubs Partition and Consumer GroupPartition — an ordered, append-only log of events. Producers route events via a partition key; events with the same key always land in the same partition (preserves per-key order). Configurable 1–32 at namespace creation (more with Premium / Dedicated). Consumer Group — a logical view of the stream; each consumer group has its own checkpointed read position.…

Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.

Turn recall into an architecture answer

For recommend an event-driven architecture, state: choose X because constraints A and B apply; reject Y because it fails C; validate with evidence D.

Ninety-second explanation

Without notes, explain:

  1. What requirement signals this learning objective rather than a neighbouring one?
  2. Which two solution families are most likely to be compared?
  3. Which hard constraint eliminates the strongest distractor?
  4. What identity, network, data, or failure boundary must appear in the design?
  5. Which operational test would prove the recommendation works?

Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.

Loading flashcards…

When to open the full lesson

Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.

Source and freshness

Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.

All Designing Microsoft Azure Infrastructure Solutions (AZ-305) Study Resources

Related Notes

  • Recommend an Event-Driven Architecture — Lesson4,458 words
  • AZ-305 Exam Map and Design Decision Playbook652 words
  • Unit 1 Capstone — Design identity, governance, and monitoring solutions668 words
  • Unit 1 Roadmap — Design identity, governance, and monitoring solutions639 words
  • Cram Sheet — Design authentication and authorization solutions632 words
  • Design Authentication and Authorization Solutions — Lesson4,263 words
  • Design Studio — Design authentication and authorization solutions734 words
  • Quick Note — Recommend an Authentication Solution758 words
  • Recommend an Authentication Solution — Lesson4,868 words
  • Quick Note — Recommend an Identity Management Solution796 words
  • Recommend an Identity Management Solution — Lesson5,982 words
  • Quick Note — Recommend a Solution for Authorizing Access to Azure Resources745 words

Ready to study Designing Microsoft Azure Infrastructure Solutions (AZ-305)?

Practice tests, flashcards, and all study notes — free, no sign-up.

Start Studying

Ready to study Designing Microsoft Azure Infrastructure Solutions (AZ-305)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free
Designing Microsoft Azure Infrastructure Solutions (AZ-305) ResourcesExplore All HivesBlogHome

© 2026 BrainyBee. Free AI-powered exam prep.

Recommend an Event-Driven Architecture — quick retrieval

Card 1 of 4

Front of flashcard 1 of 4

Azure Event Grid

easy

A push-based event-routing service for discrete state-change events. Sources publish events; Event Grid routes to subscribed handlers (Functions, Logic Apps, webhooks, Event Hubs). Native system topics for Azure services (Storage blob created, RG deployment complete, Resource modified, AKS health). Custom topics for app-generated events. At-least-once delivery, 242424-h retry, DLQ to Blob.

event-grid

Recommend an Event-Driven Architecture — quick retrieval

Card 1

Front

Azure Event Grid

Back

A push-based event-routing service for discrete state-change events. Sources publish events; Event Grid routes to subscribed handlers (Functions, Logic Apps, webhooks, Event Hubs). Native system topics for Azure services (Storage blob created, RG deployment complete, Resource modified, AKS health). Custom topics for app-generated events. At-least-once delivery, 242424-h retry, DLQ to Blob.

Card 2

Front

Azure Event Hubs

Back

A big-data streaming ingest service. Ingests millions of events/second; events sit in partitions (ordered, append-only logs) for 111–777 days (longer with Capture or Premium dedicated). Pull-based consumers (consumer groups). Use for telemetry firehose, app logs, IoT, click streams — anything where each event is small but volume is huge.

Card 3

Front

Event Grid system topic vs custom topic

Back

System topic — Azure-emitted events from a specific resource (Storage account 'BlobCreated', Subscription 'ResourceWriteSuccess', AKS, ACR, etc.). Auto-created when you subscribe. Custom topic — you create the topic, your apps publish events to it via SDK / REST. Subscribers can be any Event Grid handler. Use custom topics to publish your own domain events ('OrderPlaced', 'CustomerSignedUp').

Card 4

Front

Event Hubs Partition and Consumer Group

Back

Partition — an ordered, append-only log of events. Producers route events via a partition key; events with the same key always land in the same partition (preserves per-key order). Configurable 111–323232 at namespace creation (more with Premium / Dedicated). Consumer Group — a logical view of the stream; each consumer group has its own checkpointed read position.…

Recommend an Event-Driven Architecture — quick retrieval

Card 1

Front

Azure Event Grid

Back

A push-based event-routing service for discrete state-change events. Sources publish events; Event Grid routes to subscribed handlers (Functions, Logic Apps, webhooks, Event Hubs). Native system topics for Azure services (Storage blob created, RG deployment complete, Resource modified, AKS health). Custom topics for app-generated events. At-least-once delivery, 242424-h retry, DLQ to Blob.

Card 2

Front

Azure Event Hubs

Back

A big-data streaming ingest service. Ingests millions of events/second; events sit in partitions (ordered, append-only logs) for 111–777 days (longer with Capture or Premium dedicated). Pull-based consumers (consumer groups). Use for telemetry firehose, app logs, IoT, click streams — anything where each event is small but volume is huge.

Card 3

Front

Event Grid system topic vs custom topic

Back

System topic — Azure-emitted events from a specific resource (Storage account 'BlobCreated', Subscription 'ResourceWriteSuccess', AKS, ACR, etc.). Auto-created when you subscribe. Custom topic — you create the topic, your apps publish events to it via SDK / REST. Subscribers can be any Event Grid handler. Use custom topics to publish your own domain events ('OrderPlaced', 'CustomerSignedUp').

Card 4

Front

Event Hubs Partition and Consumer Group

Back

Partition — an ordered, append-only log of events. Producers route events via a partition key; events with the same key always land in the same partition (preserves per-key order). Configurable 111–323232 at namespace creation (more with Premium / Dedicated). Consumer Group — a logical view of the stream; each consumer group has its own checkpointed read position.…