Choosing Communication Patterns in Architecture Conversations

Goal

Architecture conversations reward clear reasoning more than service-name speed. This section turns the chapter into a practical answer pattern for design reviews, interviews, and brainstorming sessions.

The Short Version

A strong integration answer names the constraint, the pattern, and the failure behavior.

Use this checklist:

Need -> pattern -> AWS service family -> failure controls -> monitoring -> trade-off

If you can explain those six pieces, your answer will sound like architecture rather than a list of AWS products.

A Conversation-Ready Structure

When someone asks how systems should communicate, answer in this order:

1. Restate the business or user need.

2. Name the communication need: immediate answer, durable work, fanout, event routing, or orchestration.

3. Compare the realistic options.

4. Recommend the simplest pattern that fits.

5. Name the trade-offs.

6. Describe failure handling.

7. Describe observability and ownership.

8. Name what you would validate next.

This structure keeps the answer grounded. It also makes room for nuance, which is where architecture judgment usually shows up.

Weak Answers And Better Answers

A weak answer says:

Use events for everything.

A stronger answer says:

Use synchronous APIs only where the caller needs an immediate answer. Use queues for durable background work, events for notifications, and workflows for stateful multi-step coordination. Then design idempotency, retries, DLQs, schema ownership, tracing, and alarms.

Another weak answer says:

Use Step Functions because it has a diagram.

A stronger answer says:

Use Step Functions when the process has state, branching, retries, timeouts, compensation, or needs visible execution history. If the work is simply "process these jobs when workers are ready," SQS plus workers may be simpler.

Example: Compare The Main Patterns

If asked to compare SQS, SNS, EventBridge, and Step Functions, you can say:

That answer explains intent before implementation. It also leaves space for combined patterns, such as SNS fanout to multiple SQS queues, or EventBridge starting a Step Functions workflow.

Tie The Recommendation To Risk

Integration choices should connect to user experience, business risk, team skill, and operations.

For example:

• If latency affects checkout, keep the synchronous path small.

• If lost work affects revenue, use durable queues and reconciliation.

• If many teams consume an event, define schema ownership and compatibility rules.

• If steps must be audited, coordinated, or compensated, use workflow orchestration.

• If the team cannot operate the pattern, simplify the design.

The practical answer is rarely the fanciest diagram. It is the pattern the team can operate safely.

Common Mistakes

• Reciting service names without explaining why.

• Ignoring failure behavior in a supposedly resilient design.

• Promising exactly-once outcomes casually instead of designing idempotency and reconciliation.

• Treating asynchronous design as automatically simpler.

• Forgetting that observability and ownership are part of the communication contract.

If Someone Asks You

How do you explain AWS event-driven architecture in a practical way?

A good answer is:

I explain it as choosing communication contracts. APIs are for immediate answers, queues are for durable buffered work, topics and event buses are for notifying and routing events, and workflows coordinate multi-step processes. Then I make the failure behavior visible: idempotency, retries, DLQs, ordering, schema evolution, replay, tracing, metrics, alarms, and ownership.

What You Should Remember

Integration recommendations should make trade-offs and failure behavior visible.

Questions to Check Your Understanding

1. What makes an integration answer conversation-ready?

2. Which trade-offs appear when moving from API calls to events?

3. Why should failure behavior be part of the first design conversation?