Backend interview prep

Start

Events vs Commands Interview Questions and Answers

Learn the difference between Events and Commands with interview questions, Mermaid diagrams, Spring Boot examples, Kafka integration, and enterprise event-driven architecture best practices.

Events vs Commands - Interview Questions & Answers

One of the most frequently asked Event-Driven Architecture interview questions is:

What is the difference between an Event and a Command?

Although both are messages exchanged between services, they represent completely different concepts.

Understanding this difference is essential for building scalable microservices using Kafka, RabbitMQ, ActiveMQ, and Spring Boot.

Event vs Command Architecture

flowchart LR

Client --> OrderService["Order Service"]

OrderService["Order Service"] -- Command --> PaymentService["Payment Service"]

PaymentService["Payment Service"] -- PaymentCompleted Event --> Kafka

Kafka --> NotificationService["Notification Service"]

Kafka --> AnalyticsService["Analytics Service"]

Kafka --> RewardService["Reward Service"]

Q1. What is a Command?

Answer

A Command is a request asking another service to perform an action.

A command represents intent.

Examples:

  • Create Order
  • Process Payment
  • Reserve Inventory
  • Generate Invoice
  • Send Email

Commands expect one specific service to handle the request.

Command Flow

flowchart LR

OrderService["Order Service"] -- Process Payment --> PaymentService["Payment Service"]

Characteristics

  • Intent to perform work
  • One destination
  • Usually synchronous or point-to-point
  • Often expects acknowledgement

Q2. What is an Event?

Answer

An Event represents something that has already happened.

It is a notification about a completed business action.

Examples:

  • Order Created
  • Payment Completed
  • Customer Registered
  • Shipment Delivered

Events do not request action.

They simply inform interested systems.

Event Flow

flowchart LR

PaymentService["Payment Service"] -- Payment Completed --> Kafka

Kafka --> NotificationService["Notification Service"]

Kafka --> AnalyticsService["Analytics Service"]

Kafka --> FraudService["Fraud Service"]

Characteristics

  • Represents completed work
  • Immutable
  • Broadcast to multiple consumers
  • No expectation of response

Q3. What is the difference between Events and Commands?

Answer

Feature Command Event
Meaning Request to perform work Notification that work completed
Direction One target Many subscribers
Coupling Higher Lower
Ownership Sender decides Consumers decide
Response Usually expected Not expected

Comparison

flowchart TD

Command --> SingleService["Single Service"]

Event --> MultipleServices["Multiple Services"]

Interview Tip

Command = "Please do this."

Event = "This already happened."

Q4. When should we use Commands?

Answer

Commands should be used when exactly one service must perform an operation.

Examples:

  • Create Customer
  • Process Payment
  • Reserve Inventory
  • Generate Invoice
  • Approve Loan

Command Example

flowchart LR

CheckoutService["Checkout Service"] -- Reserve Inventory --> InventoryService["Inventory Service"]

Only the Inventory Service should process this request.

Q5. When should we use Events?

Answer

Events are appropriate when multiple systems may be interested in the outcome.

Examples:

  • Order Created
  • Payment Successful
  • Customer Registered
  • Loan Approved

Event Example

flowchart LR

OrderService["Order Service"] -- Order Created --> Kafka

Kafka --> InventoryService["Inventory Service"]

Kafka --> ShippingService["Shipping Service"]

Kafka --> NotificationService["Notification Service"]

Kafka --> AnalyticsService["Analytics Service"]

Every consumer receives the event independently.

Q6. How do Commands and Events work together?

Answer

In real-world systems, commands often produce events.

Example workflow:

  1. Checkout Service sends Process Payment command.
  2. Payment Service processes the payment.
  3. Payment Service publishes Payment Completed event.
  4. Other services react independently.

Workflow

sequenceDiagram
participant Checkout
participant Payment
participant Kafka
participant Notification
Checkout->>Payment: Process Payment (Command)
Payment-->>Kafka: Payment Completed (Event)
Kafka-->>Notification: Notify Customer

Q7. How does Spring Boot implement Commands and Events?

Answer

Spring Boot supports both communication styles.

Commands:

  • REST APIs
  • gRPC
  • RabbitMQ Queue
  • ActiveMQ Queue

Events:

  • Kafka Topics
  • RabbitMQ Topics
  • Spring Cloud Stream
  • Spring Events

Spring Boot

flowchart TD

SpringBoot["Spring Boot"] --> RestCommand["REST Command"]

RestCommand["REST Command"] --> PaymentService["Payment Service"]

PaymentService["Payment Service"] --> KafkaEvent["Kafka Event"]

KafkaEvent["Kafka Event"] --> Consumers

Best Practice

Use REST for immediate business operations and Kafka for business events.

Q8. What are common implementation mistakes?

Answer

Common mistakes include:

  • Naming commands as events
  • Using events to request work
  • Using commands for broadcasting
  • Coupling consumers together
  • Mutable events
  • Multiple services processing one command

Wrong Design

PaymentCompleted

↓

Please Process Payment ❌

Correct Design

Process Payment

↓

Payment Completed ✅

Q9. What are the benefits of Events over Commands?

Answer

Events provide:

  • Loose Coupling
  • Better Scalability
  • Independent Deployments
  • Easy Integration
  • Event Replay
  • Multiple Consumers

Commands provide:

  • Direct Control
  • Immediate Processing
  • Simpler Business Transactions

Benefits

mindmap
  root((Communication))
    Commands
      Direct Action
      Single Target
    Events
      Loose Coupling
      Broadcast
      Replay
      Scalability

Q10. What are the enterprise best practices for Events and Commands?

Answer

Follow these recommendations:

Commands

  • Keep commands specific.
  • One command → One handler.
  • Validate before execution.
  • Avoid broadcasting commands.

Events

  • Keep events immutable.
  • Publish only completed business actions.
  • Version event schemas.
  • Use idempotent consumers.
  • Monitor event processing.
  • Enable replay.

Enterprise Architecture

flowchart TD

Client --> OrderService["Order Service"]

OrderService["Order Service"] -- Create Order Command --> OrderProcessor["Order Processor"]

OrderProcessor["Order Processor"] -- Order Created Event --> Kafka

Kafka --> Inventory

Kafka --> Shipping

Kafka --> Notification

Kafka --> Analytics

Enterprise Workflow

flowchart LR

Command --> BusinessService["Business Service"]

BusinessService["Business Service"] --> Event

Event --> MultipleConsumers["Multiple Consumers"]

Events vs Commands

mindmap
  root((Events vs Commands))
    Commands
      Request
      Single Consumer
      Action
    Events
      Notification
      Multiple Consumers
      Immutable

Real-World Banking Example

A customer initiates a fund transfer.

Customer Clicks Transfer

↓

Transfer Command

↓

Payment Service

↓

Payment Processed

↓

PaymentCompleted Event

↓

Notification Service

↓

Fraud Detection

↓

Analytics

↓

Audit Service

The command initiates the payment, while the event informs other services that the payment has already completed.

Senior Interview Tip

Understanding the distinction between Commands and Events is essential for designing maintainable microservices.

A production-ready architecture typically uses:

Commands

  • REST
  • gRPC
  • RabbitMQ Queue
  • ActiveMQ Queue

Events

  • Kafka Topics
  • RabbitMQ Topic Exchange
  • Event Bus
  • Spring Cloud Stream

Enterprise implementations also include:

  • Schema Registry
  • Event Versioning
  • Dead Letter Queues (DLQ)
  • Retry Topics
  • Replay Services
  • Idempotent Consumers
  • Correlation IDs
  • Distributed Tracing
  • Monitoring (Prometheus & Grafana)

Remember:

  • Commands express intent.
  • Events describe completed business actions.
  • Commands tell a service what to do.
  • Events tell the world what has already happened.

Quick Revision

  • A Command requests a specific service to perform an action.
  • An Event notifies interested systems that an action has already occurred.
  • Commands have a single target; events can have many subscribers.
  • Commands are action-oriented; events are fact-oriented.
  • Commands usually expect acknowledgement; events generally do not.
  • Commands often result in events after successful processing.
  • Keep events immutable and versioned.
  • Use idempotent consumers for event processing.
  • Monitor command execution and event delivery separately.
  • Combine commands for business actions and events for system-wide notifications in enterprise architectures.