Event vs Command — What Is the Difference?

In microservices and message-based communication, Command and Event are both messages, but they express very different intentions.

The simplest distinction is:

Command = “Please do this.”
Event = “This has happened.”

1. What Is a Command?

A Command is a message requesting that a specific action be performed.

Examples:

CreateOrder
ProcessPayment
ReserveInventory
SendEmail
CancelOrder
GenerateInvoice

A command expresses an intention/request.

For example:

Order Service
     │
     │ ProcessPayment
     ▼
Payment Queue
     │
     ▼
Payment Service

Here, the Order Service is telling the Payment Service:

Process this payment.

The payment has not happened yet.

2. What Is an Event?

An Event is a message announcing that something already happened.

Examples:

OrderCreated
PaymentCompleted
InventoryReserved
EmailSent
OrderCancelled
InvoiceGenerated

For example:

Payment Service
      │
      │ PaymentCompleted
      ▼
   Payments Topic
      │
      ├──> Order Service
      ├──> Notification Service
      └──> Analytics Service

The Payment Service is not asking these services to perform a specific action.

It is simply announcing:

Payment has completed.

Interested services decide how to react.

3. Simple Example

Consider an ATM.

You request:

WithdrawMoney

That's a Command.

After successful withdrawal:

MoneyWithdrawn

That's an Event.

So:

COMMAND
WithdrawMoney
      ↓
"Please withdraw ₹5,000"

EVENT
MoneyWithdrawn
      ↓
"₹5,000 was withdrawn"

4. Main Difference

5. Naming Convention

Naming makes the difference easy to understand.

Commands

Use action-oriented names:

CreateOrder
ProcessPayment
ReserveInventory
SendEmail
CancelOrder

Think:

Do this.

Events

Use past-tense names:

OrderCreated
PaymentCompleted
InventoryReserved
EmailSent
OrderCancelled

Think:

This happened.

6. Command Flow

Suppose an Order Service wants payment processed.

Order Service
     │
     │ ProcessPayment
     ▼
Payment Queue
     │
     ▼
Payment Service
     │
     ▼
Process payment

The command might contain:

{
  "commandId": "CMD-1001",
  "orderId": 5001,
  "amount": 2500,
  "currency": "INR"
}

The message says:

Payment Service, please process ₹2,500 for Order 5001.

7. Event Flow

After Payment Service successfully processes the payment:

Payment Service
      │
      │ PaymentCompleted
      ▼
Payment Topic
      │
      ├──> Order Service
      ├──> Notification Service
      └──> Analytics Service

Event:

{
  "eventId": "EVT-5001",
  "eventType": "PaymentCompleted",
  "orderId": 5001,
  "amount": 2500,
  "occurredAt": "2026-09-29T08:30:00Z"
}

It says:

Payment for Order 5001 has completed.

8. Who Receives the Message?

This is another major difference.

Command — Usually One Logical Handler

Suppose:

ProcessPayment

We don't normally want:

                  ┌──> Payment Service A
ProcessPayment ───┼──> Payment Service B
                  └──> Payment Service C

All charge customer ❌

Instead:

ProcessPayment
      ↓
Payment Queue
      ↓
One Payment Worker

There may be several Payment Service instances:

                 ┌──> Payment Instance 1
Payment Queue ───┼──> Payment Instance 2
                 └──> Payment Instance 3

but they are competing consumers.

One instance handles a particular command.

9. Event — Can Have Multiple Subscribers

For:

PaymentCompleted

many services may need to know.

                     PaymentCompleted
                           │
                           ▼
                      Payment Topic
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
         Order         Notification   Analytics
         Service          Service      Service

All three can react independently.

For example:

Order Service
→ Change order status to Paid

Notification Service
→ Send payment confirmation

Analytics Service
→ Record revenue

This is classic Event-Driven Architecture.

10. Command Can Be Rejected

A command is a request, so it can fail.

Example:

ProcessPayment
      ↓
Payment Service
      ↓
Card declined
      ↓
Command cannot complete

Or:

ReserveInventory
      ↓
Inventory Service
      ↓
Product out of stock

The requested action could not be performed.

11. Event Represents a Fact

Suppose:

PaymentCompleted

has been published correctly after the payment completed.

The consumer doesn't decide:

Should the payment have completed?

That fact has already occurred.

Instead, the consumer decides:

What should I do because the payment completed?

For example:

PaymentCompleted
       │
       ├──> Order Service
       │       ↓
       │   Mark order paid
       │
       ├──> Notification
       │       ↓
       │   Send receipt
       │
       └──> Analytics
               ↓
           Record revenue

12. Command and Event Can Work Together

Commands and events commonly appear in the same business workflow.

Consider an order:

CreateOrder              ← Command
     ↓
Order Service
     ↓
OrderCreated             ← Event
     ↓
ReserveInventory         ← Command
     ↓
Inventory Service
     ↓
InventoryReserved        ← Event
     ↓
ProcessPayment           ← Command
     ↓
Payment Service
     ↓
PaymentCompleted         ← Event

This is an important pattern.

You can remember it as:

Command
   ↓
Perform Action
   ↓
Event
   ↓
Reaction
   ↓
Another Command
   ↓
Another Event

13. Complete Microservices Example

Consider:

Order Service
Inventory Service
Payment Service
Shipping Service
Notification Service

The workflow could be:

Client
  │
  │ CreateOrder
  ▼
Order Service
  │
  │ OrderCreated
  ▼
Message Broker
  │
  ▼
Inventory Workflow
  │
  │ ReserveInventory
  ▼
Inventory Service
  │
  │ InventoryReserved
  ▼
Message Broker
  │
  ▼
Payment Workflow
  │
  │ ProcessPayment
  ▼
Payment Service
  │
  │ PaymentCompleted
  ▼
Message Broker
  │
  ├──> Shipping
  ├──> Notification
  └──> Analytics

Commands request work.

Events communicate results/facts.

14. Queue vs Topic Connection

There is a useful relationship:

COMMAND
   ↓
Usually Queue
   ↓
One logical handler

Example:

ProcessPayment
      ↓
Payment Queue
      ↓
Payment Service

Whereas:

EVENT
   ↓
Usually Topic / Pub-Sub
   ↓
Multiple subscribers

Example:

PaymentCompleted
      ↓
Payment Topic
      ├──> Order
      ├──> Notification
      └──> Analytics

But this is not an absolute rule

Don't define Command vs Event merely by whether it uses a queue or topic.

The semantic meaning is the real distinction:

Command = request/intention
Event   = fact that occurred

15. Command Sender Knows the Purpose

When sending:

ProcessPayment

the sender knows what action it wants performed.

Order Service
     │
     │ "Process this payment"
     ▼
Payment Service

There is an explicit business intention.

16. Event Producer Doesn't Control Consumer Behavior

Suppose Order Service publishes:

OrderCreated

Order Service should not need to know every reaction:

Inventory → Reserve stock
Email     → Send confirmation
Analytics → Record statistics
Loyalty   → Add points

It simply announces:

OrderCreated

Consumers decide how to react.

This reduces coupling.

17. Adding a New Event Consumer

Initially:

OrderCreated
     │
     ├──> Inventory
     └──> Notification

Later the business wants analytics.

Add:

OrderCreated
     │
     ├──> Inventory
     ├──> Notification
     └──> Analytics

The Order Service may not need to change at all.

This is one of the major advantages of event-driven systems.

18. Command Example in C#

A simple command:

public class ProcessPaymentCommand
{
    public Guid CommandId { get; set; }

    public int OrderId { get; set; }

    public decimal Amount { get; set; }
}

Creating it:

var command = new ProcessPaymentCommand
{
    CommandId = Guid.NewGuid(),
    OrderId = 1001,
    Amount = 2500
};

Conceptually:

ProcessPaymentCommand
       ↓
Payment Queue
       ↓
Payment Service

19. Event Example in C#

After successful payment:

public class PaymentCompletedEvent
{
    public Guid EventId { get; set; }

    public int OrderId { get; set; }

    public decimal Amount { get; set; }

    public DateTime OccurredAt { get; set; }
}

Create:

var paymentCompleted =
    new PaymentCompletedEvent
    {
        EventId = Guid.NewGuid(),
        OrderId = 1001,
        Amount = 2500,
        OccurredAt = DateTime.UtcNow
    };

Publish:

PaymentCompletedEvent
         ↓
Payment Topic
         │
         ├──> Order Service
         ├──> Notification Service
         └──> Analytics Service

20. Should Commands Return Results?

Conceptually, a command has an outcome:

ProcessPayment
     ↓
SUCCESS / FAILURE

With synchronous commands, the result might be returned immediately.

Client
  │ ProcessPayment
  ▼
Payment API
  │
  ▼
PaymentResult

With asynchronous messaging, the outcome may instead be communicated through another message/event:

ProcessPayment
      ↓
Payment Queue
      ↓
Payment Service
      │
      ├── PaymentCompleted
      │
      └── PaymentFailed

This is very common in asynchronous microservices.

21. Should Events Return Results?

Normally, no.

An event is a notification of something that happened.

OrderCreated

The producer doesn't normally publish OrderCreated and wait for:

Inventory Response
Email Response
Analytics Response
Loyalty Response

That would reintroduce tight coupling.

Instead:

OrderCreated
      ↓
Publish
      ↓
Continue

Consumers react independently.

22. Event Immutability

Events should generally be treated as immutable facts.

Suppose:

PaymentCompleted
Amount = ₹2,500

was published.

Later, don't conceptually modify that historical event into:

PaymentCompleted
Amount = ₹3,000

If something later changes, publish another event representing that new fact.

For example:

PaymentRefunded

Events represent historical occurrences.

23. Failure Example

Suppose Order Service sends:

ReserveInventory

Inventory Service checks:

Available stock = 0

The command cannot succeed.

It may publish:

InventoryReservationFailed

Flow:

ReserveInventory                ← Command
        ↓
Inventory Service
        ↓
Check stock
        ↓
No stock
        ↓
InventoryReservationFailed      ← Event

This clearly shows the difference:

ReserveInventory
      ↓
"Please do this"

InventoryReservationFailed
      ↓
"This happened"

24. Event vs Command vs Query

For interviews, it's useful to know all three.

Easy way to remember:

COMMAND
"Do something"

QUERY
"Tell me something"

EVENT
"Something happened"

25. CQRS Connection

This also relates to CQRS — Command Query Responsibility Segregation.

CQRS separates:

Commands
    ↓
Change system state

Queries
    ↓
Read system state

For example:

CreateOrderCommand
UpdateOrderCommand
CancelOrderCommand

GetOrderQuery
GetOrdersQuery

After a command changes state, the system may publish an event:

CreateOrderCommand
       ↓
Order created
       ↓
OrderCreatedEvent

So:

Command
   ↓
Change State
   ↓
Event

is a very common architecture.

26. Advantages of Commands

Commands make business intention explicit.

Instead of a vague message:

PaymentData

you have:

ProcessPayment

Benefits include:

• Clear business intent
• Clear ownership
• Easier validation
• Natural fit for work queues
• Easier authorization decisions
• Easier to reason about expected behavior

27. Disadvantages of Commands

Commands can create coupling if poorly designed.

For example:

Order Service
   ↓
SendCustomerEmailCommand

Now Order Service knows that an email must be sent.

Maybe Order Service should instead publish:

OrderCreated

and let Notification Service decide:

OrderCreated
     ↓
Notification Service
     ↓
Send Email

This can produce looser coupling.

28. Advantages of Events

Events provide:

• Loose coupling
• Multiple independent subscribers
• Easy extensibility
• Natural support for Event-Driven Architecture
• Asynchronous processing
• Independent service reactions
• Better integration across bounded contexts

For example:

OrderCreated
     ├──> Inventory
     ├──> Notification
     ├──> Analytics
     └──> Loyalty

29. Disadvantages of Events

Too many events can make systems difficult to understand.

You can end up with:

OrderCreated
    ↓
InventoryReserved
    ↓
PaymentRequested
    ↓
PaymentCompleted
    ↓
ShipmentCreated
    ↓
WarehouseNotified
    ↓
...

This introduces challenges such as:

• Eventual consistency
• Debugging complexity
• Distributed tracing
• Duplicate processing
• Ordering
• Schema/version management
• Error handling
• Retry handling

Correlation IDs and good observability become important.

30. Common Mistake: Naming a Command as an Event

Bad:

PaymentProcess
OrderCreate
InventoryReserve

Better commands:

ProcessPayment
CreateOrder
ReserveInventory

Events:

PaymentCompleted
OrderCreated
InventoryReserved

The name should make the semantic meaning obvious.

31. Common Mistake: Using an Event as an Instruction

Suppose Order Service publishes:

SendOrderConfirmationEmail

and calls it an event.

That's really a command, because it tells another service what to do.

A better event might be:

OrderCreated

Then Notification Service decides:

OrderCreated
     ↓
Should we notify customer?
     ↓
Send confirmation

This keeps the producer less coupled to the consumer's behavior.

32. Real-World Design

A typical order workflow might look like:

                   CreateOrder
                       │
                    COMMAND
                       ▼
                ┌──────────────┐
                │Order Service │
                └──────┬───────┘
                       │
                  OrderCreated
                       │
                     EVENT
                       ▼
                  Message Broker
                       │
                       ▼
               ReserveInventory
                       │
                    COMMAND
                       ▼
             ┌─────────────────┐
             │Inventory Service│
             └────────┬────────┘
                      │
              InventoryReserved
                      │
                    EVENT
                      ▼
                 Message Broker
                      │
                      ▼
                ProcessPayment
                      │
                   COMMAND
                      ▼
              ┌───────────────┐
              │Payment Service│
              └───────┬───────┘
                      │
              PaymentCompleted
                      │
                    EVENT
                      ▼
                 Message Broker
                      │
            ┌─────────┼─────────┐
            ▼         ▼         ▼
         Shipping   Email    Analytics

This illustrates the relationship very clearly:

Commands request state changes. Events announce the results/facts produced by state changes.

33. Key Points

Remember these for interviews:

• Command = request/intention.
• Event = fact/occurrence.
• Commands usually use imperative/action names.
• Events usually use past-tense names.
• ProcessPayment is a command.
• PaymentCompleted is an event.
• A command normally has one logical handler.
• An event can have zero, one, or many subscribers.
• Commands can succeed or fail.
• Events represent something that already occurred.
• Commands often fit queues.
• Events often fit topics/pub-sub.
• Queue vs Topic does not itself define Command vs Event; semantics do.
• Events should generally be treated as immutable facts.
• Asynchronous command outcomes are often represented by events.
• Commands, events, and queries are different concepts.
• CQRS separates commands from queries.
• Event-driven microservices frequently use both commands and events.

34. Interview Questions and Answers

Q1. What is the difference between a Command and an Event?

Answer:

A command requests an action to be performed, while an event announces that something has already happened.

For example:

ProcessPayment     → Command
PaymentCompleted   → Event

Q2. How should Commands and Events be named?

Answer:

Commands normally use action-oriented names:

CreateOrder
ProcessPayment
ReserveInventory

Events normally use past-tense names:

OrderCreated
PaymentCompleted
InventoryReserved

Q3. Can a Command fail?

Answer:

Yes. A command is a request, so the requested action may succeed or fail.

For example:

ProcessPayment
     ↓
Payment declined

The system may then publish:

PaymentFailed

Q4. Can an Event fail?

Answer:

The event itself represents a fact that already occurred. However, an event consumer can fail while processing that event.

For example:

OrderCreated
     ↓
Notification Service
     ↓
Email provider failure

OrderCreated remains a valid fact; the Notification Service failed to react to it.

Q5. How many consumers should a Command have?

Answer:

A command normally has one logical handler because it asks for a specific operation to be performed.

There may be multiple instances of that handler for scalability, but one instance should process a particular command.

Q6. How many consumers can an Event have?

Answer:

An event can have zero, one, or many subscribers.

For example:

OrderCreated
     ├──> Inventory
     ├──> Notification
     ├──> Analytics
     └──> Loyalty

Q7. Should Commands use Queue or Topic?

Answer:

Commands are commonly sent through a Queue because they usually have one logical handler.

ProcessPayment
      ↓
Payment Queue
      ↓
Payment Service

Q8. Should Events use Queue or Topic?

Answer:

Events commonly use a Topic/Publish-Subscribe mechanism because multiple services may need to react independently.

OrderCreated
     ↓
Topic
     ├──> Inventory
     ├──> Notification
     └──> Analytics

Q9. What is the difference between Command, Event, and Query?

Answer:

Command
→ "Do something"
→ ProcessPayment

Query
→ "Give me information"
→ GetPaymentDetails

Event
→ "Something happened"
→ PaymentCompleted

A command normally changes state, a query reads state, and an event announces a fact.

Q10. Can a Command produce an Event?

Answer:

Yes. This is very common.

ProcessPayment        ← Command
      ↓
Payment Service
      ↓
Payment succeeds
      ↓
PaymentCompleted      ← Event

Q11. Why shouldn't a producer tell every consumer what to do?

Answer:

Doing so increases coupling.

Instead of:

Order Service
   ├── SendEmail
   ├── UpdateAnalytics
   └── AddLoyaltyPoints

Order Service can publish:

OrderCreated

and interested services decide how to react.

Interview-Friendly Final Answer

A Command represents an intention or request to perform an action, while an Event represents a fact that has already occurred. Commands are normally action-oriented, such as ProcessPayment, and usually have one logical handler. Events are normally past-tense, such as PaymentCompleted, and can have multiple independent subscribers. Commands commonly fit queue-based communication, while events commonly fit topic/pub-sub communication. For example, ProcessPayment may be sent to a Payment Queue; after successful processing, the Payment Service publishes PaymentCompleted, which can be consumed by Order, Notification, Analytics, and other services.