Event-Driven Architecture in Practice: AWS vs GCP

Event-Driven Architecture (EDA) is the backbone of modern distributed systems. Instead of services calling each other directly (and creating brittle coupling), services emit events — facts about something that happened — and other services react to those events asynchronously.

This article is a practical guide to implementing EDA on the two leading cloud platforms, with real patterns you can apply today.

Why Event-Driven?

Traditional request-response architectures create a web of dependencies. Service A calls Service B, which calls Service C. When Service C is slow, everything is slow. When Service C is down, everything is down.

Event-driven systems break this chain:

• Loose Coupling: Services don’t need to know about each other.
• Resilience: If a consumer is down, the event waits. Nothing breaks.
• Scalability: Producers and consumers scale independently.
• Auditability: Every event is a record of what happened and when.

In payments—where I’ve spent my career—this isn’t optional. When a transaction flows through authorization, clearing, and settlement, each step is an event. The architecture must be resilient enough to handle millions of these per day without losing a single one.

AWS: The EventBridge Advantage

AWS has built the most complete event-driven ecosystem in the cloud, centred around Amazon EventBridge.

Core Components

Pattern 1: Domain Event Fan-Out

When a payment is processed, multiple downstream services need to react — fraud detection, notifications, analytics, settlement.

Architecture:

1. Payment Service emits a PaymentProcessed event to EventBridge.
2. EventBridge rules route the event based on content:
   • amount > 10000 → Fraud Review Queue (SQS)
   • type = "international" → Compliance Lambda
   • All events → Analytics Kinesis Stream
3. Each consumer processes independently. If fraud review is slow, notifications still fire instantly.

Why this works: EventBridge’s content-based routing means you don’t need a central orchestrator deciding where events go. The rules engine does it declaratively.

Pattern 2: Saga Orchestration

For long-running business processes (like a refund that spans payment, inventory, and loyalty systems), use Step Functions as a saga orchestrator:

1. Step Function receives the triggering event.
2. Each step invokes a service and waits for a completion event.
3. If any step fails, compensating actions are triggered automatically.
4. The entire saga state is stored and visible in the Step Functions console — a massive operational advantage.

The Killer Feature: Schema Registry

EventBridge includes a Schema Registry that:

• Auto-discovers event shapes from your event bus
• Generates typed code bindings (TypeScript, Python, Java)
• Enforces contracts between producer and consumer teams

This solves one of the hardest problems in EDA: “What does this event look like?”

GCP: Simplicity with Pub/Sub & Eventarc

GCP takes a more streamlined approach, built on open standards.

Core Components

Pattern 1: Pub/Sub Fan-Out

The equivalent AWS Fan-Out pattern on GCP:

1. Payment Service publishes a message to a Pub/Sub topic.
2. Multiple subscriptions on that topic deliver to different consumers:
   • Push subscription → Cloud Run fraud service
   • Push subscription → Cloud Functions notification handler
   • Pull subscription → Dataflow analytics pipeline
3. Each subscription is independent. Pub/Sub guarantees at-least-once delivery and retries failed deliveries automatically.

Key difference from AWS: Pub/Sub doesn’t have built-in content-based routing. Each subscriber gets every message and must filter locally. For complex routing, you’d create separate topics.

Pattern 2: Eventarc + Cloud Run

Eventarc is GCP’s answer to “how do I connect events to containers”:

1. A Cloud Storage upload triggers an Eventarc trigger.
2. Eventarc routes the event (in CloudEvents format) to a Cloud Run service.
3. Cloud Run processes the file and publishes a result to Pub/Sub.

Why CloudEvents matters: It’s an open standard (CNCF). Your event handlers aren’t locked to GCP’s proprietary format.

The Killer Feature: Global Message Ordering

Pub/Sub supports ordering keys, letting you process events for the same entity (e.g., the same customer) in order, even at massive scale. Combined with exactly-once delivery in Dataflow, this is powerful for financial systems.

Head-to-Head: Which Should You Choose?

My Recommendation

• Choose AWS if you need complex event routing, multi-account architectures, or enterprise-grade saga orchestration. EventBridge + Step Functions is the most complete package.
• Choose GCP if you prioritise developer experience, global message delivery, and open standards. Cloud Run + Pub/Sub is simpler to operate.

Getting Started: Your First Event-Driven Service

Regardless of cloud platform, start with this pattern:

1. Pick one synchronous API call between two services.
2. Replace it with an event. The producer publishes an event; the consumer subscribes.
3. Add a dead-letter queue. Capture any events that fail processing.
4. Monitor the lag. The gap between event production and consumption is your key metric.
5. Iterate. Once you’ve proven the pattern, apply it to the next integration point.

The shift from request-response to event-driven isn’t all-or-nothing. Start small, prove the value, and expand deliberately.

Written by Haris Habib from Sydney, Australia | February 2026