Event-Driven Architecture in Practice: AWS vs GCP

Event-driven architecture is one of the most useful patterns in distributed systems.

It is also one of the easiest to misuse.

The promise is simple: instead of services calling each other directly and creating brittle chains of dependency, services publish events: facts about something that happened. Other services react asynchronously.

The trap is thinking the event bus is the architecture.

It is not.

The real architecture is the ownership model, event contract, failure handling, replay strategy, and operational visibility around the event bus.

Why Event-Driven Systems Matter

Traditional request-response systems create tight coupling. Service A calls Service B, which calls Service C. When Service C is slow, everything upstream waits. When Service C fails, upstream services fail too.

Event-driven systems break that chain.

In payments, this is not optional. Authorisation, fraud scoring, customer notification, clearing, settlement, reconciliation, and reporting all involve state changes that need to be recorded and reacted to safely.

Start With The Event Contract

Before choosing EventBridge or Pub/Sub, define the event.

A good event is a business fact, not an implementation detail.

A production event should usually include:

• event name
• event version
• event ID
• occurred-at timestamp
• producer name
• correlation ID or trace ID
• aggregate/entity ID
• business payload
• schema reference
• privacy classification where relevant

AWS: The EventBridge Advantage

AWS has one of the most complete event-driven ecosystems in the cloud, especially when centred around Amazon EventBridge.

Pattern: Domain Event Fan-Out

When a payment is processed, multiple services may need to react: fraud review, notification, analytics, reconciliation, and settlement.

On AWS:

1. The payment service publishes PaymentProcessed to EventBridge.
2. EventBridge routes events by content and rule.
3. High-risk payments go to an SQS fraud queue.
4. International payments trigger compliance processing.
5. All payment events flow into analytics.
6. Each consumer processes independently and owns its own retries.

EventBridge’s content-based routing is valuable because routing logic can be declarative rather than buried inside one central orchestrator.

Pattern: Saga Orchestration

For long-running workflows, Step Functions can coordinate the process.

A refund might need to update payment state, inventory, customer notification, loyalty points, and ledger entries. If one step fails, compensating actions may be required.

Step Functions gives operators a visible execution history. That visibility is not a nice-to-have. It is what makes a failed distributed workflow diagnosable.

GCP: Pub/Sub, Eventarc, And Cloud Run

GCP takes a simpler and more developer-friendly approach, with strong support for containers and open event standards.

Pattern: Pub/Sub Fan-Out

On GCP:

1. The payment service publishes PaymentProcessed to a Pub/Sub topic.
2. Multiple subscriptions deliver the event to different consumers.
3. A Cloud Run fraud service processes one subscription.
4. A Cloud Functions notification handler processes another.
5. Dataflow consumes another stream for analytics.

Each subscription has its own retry and acknowledgement lifecycle. That is a clean model for independent consumers.

The main difference from EventBridge is routing. Pub/Sub is excellent at delivery and scale, but content-based routing usually requires topic design, filters, Eventarc, or logic in the consumer.

Pattern: Eventarc + Cloud Run

Eventarc shines when you want cloud events delivered into containerised services.

For example, a file upload to Cloud Storage can trigger Eventarc, which delivers a CloudEvents-formatted event to Cloud Run. Cloud Run processes the file, writes metadata, and publishes a result to Pub/Sub.

CloudEvents is valuable because it gives teams a standard event envelope instead of a platform-specific shape.

AWS vs GCP: The Decision Table

The right choice depends less on the service names and more on your operating constraints.

The Failure Handling Checklist

An event-driven system is not production-ready until it answers these questions:

Security And Well-Architected Gaps To Call Out

Event-driven systems often fail quietly because the failure is spread across producers, brokers, consumers, queues, and dashboards.

The Well-Architected gap is usually operational excellence plus security. A good event platform should make ownership, contracts, failure, replay, cost, and access visible. If the team cannot answer who owns an event and what happens when it fails, the architecture is not ready.

Getting Started

Start small.

1. Pick one synchronous integration that causes coupling or reliability pain.
2. Define the business event in domain language.
3. Create the event contract and owner.
4. Publish the event from the source service.
5. Add one consumer.
6. Add retry, dead-letter, alerting, and replay from day one.
7. Measure latency, lag, failure rate, and business outcome.

Do not event-source your whole company because a diagram looked elegant.

Use events where they reduce coupling, improve resilience, create useful audit history, or allow independent services to react to business facts.

The Real Lesson

Event-driven architecture is not about making everything asynchronous.

It is about making business change visible, durable, and safely consumable by the rest of the system.

AWS gives you powerful routing and workflow primitives. GCP gives you clean global messaging, Cloud Run simplicity, and open event standards.

Both can work well.

Both can become chaos.

The difference is whether your events have clear meaning, ownership, contracts, recovery paths, and observability.

Sources and Further Reading

• AWS Well-Architected Framework
• Google Cloud Well-Architected Framework

Written by Haris Habib from Sydney, Australia | February 2026