Comparison questionMedium~7 minQueue Basics / 3 of 7

Interview question

What is the difference between sending a command and publishing an event?

Distinguish commands and events in message-driven systems

Explains command messages versus event messages and how ownership changes their design.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A command asks a specific receiver to do something, like SendWelcomeEmail or GenerateInvoice. It carries intent and usually has one logical owner. An event announces that something already happened, like UserRegistered or OrderPaid. It is a fact that multiple consumers can react to independently. I would name messages so that intent versus fact is obvious.

Full answer below

Practice focus

Command ownership, event facts, intent versus history, naming, coupling, and consumer expectations.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Command and event confusion creates messy distributed systems. The distinction matters because it changes who owns the action and how tightly services are coupled.
A command asks a specific receiver to do something, like SendWelcomeEmail or GenerateInvoice. It carries intent and usually has one logical owner. An event announces that something already happened, like UserRegistered or OrderPaid. It is a fact that multiple consumers can react to independently. I would name messages so that intent versus fact is obvious.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would use commands when the sender knows which capability needs to run and expects that work to happen. I would use events when the publisher owns the state change and wants other systems to react without knowing all future consumers. Events reduce direct coupling, but they create schema and timing contracts. Commands are often easier to reason about for work queues, but they can couple the sender to a receiver's responsibility.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production message ownership is visible in names, contracts, routing, and operational responsibility. A command has one logical handler and a defined failure outcome; an event records a fact and does not assume which subscribers exist. State changes and emitted events use an outbox when they must be atomic, and both commands and events carry stable identifiers for duplicate handling. Contract versioning, authorization at the receiving boundary, correlation, and audit trails remain explicit rather than being hidden behind a generic message bus abstraction.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Naming commands as past-tense events or events as imperative commands.
Putting receiver-specific instructions into a public event.
Assuming events remove all coupling.
Ignoring duplicate delivery for commands.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain intent versus fact.
Does not know who owns the message contract.
Treats events as async method calls.
Has no compatibility story for event consumers.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Is SendEmailRequested a command or an event?
Who owns an event schema?
How would you add a new event consumer later?

Continue the section

Next in Queue Basics: Competing Consumers

Step 4 of 7

Scale queue processing with competing consumers

Opening drill

Comparison questionMedium~7 minQueue Basics / 3 of 7

Interview question

What is the difference between sending a command and publishing an event?

Distinguish commands and events in message-driven systems

Explains command messages versus event messages and how ownership changes their design.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Command ownership, event facts, intent versus history, naming, coupling, and consumer expectations.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Command and event confusion creates messy distributed systems. The distinction matters because it changes who owns the action and how tightly services are coupled.
A command asks a specific receiver to do something, like SendWelcomeEmail or GenerateInvoice. It carries intent and usually has one logical owner. An event announces that something already happened, like UserRegistered or OrderPaid. It is a fact that multiple consumers can react to independently. I would name messages so that intent versus fact is obvious.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would use commands when the sender knows which capability needs to run and expects that work to happen. I would use events when the publisher owns the state change and wants other systems to react without knowing all future consumers. Events reduce direct coupling, but they create schema and timing contracts. Commands are often easier to reason about for work queues, but they can couple the sender to a receiver's responsibility.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production message ownership is visible in names, contracts, routing, and operational responsibility. A command has one logical handler and a defined failure outcome; an event records a fact and does not assume which subscribers exist. State changes and emitted events use an outbox when they must be atomic, and both commands and events carry stable identifiers for duplicate handling. Contract versioning, authorization at the receiving boundary, correlation, and audit trails remain explicit rather than being hidden behind a generic message bus abstraction.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Naming commands as past-tense events or events as imperative commands.
Putting receiver-specific instructions into a public event.
Assuming events remove all coupling.
Ignoring duplicate delivery for commands.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain intent versus fact.
Does not know who owns the message contract.
Treats events as async method calls.
Has no compatibility story for event consumers.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Is SendEmailRequested a command or an event?
Who owns an event schema?
How would you add a new event consumer later?

Continue the section

Next in Queue Basics: Competing Consumers

Step 4 of 7

Scale queue processing with competing consumers

What is the difference between sending a command and publishing an event?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

What is the difference between sending a command and publishing an event?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section