Why Event schema design in Microservices? - Purpose & Use Cases

The Big Idea

What if a tiny change in message format could stop hours of debugging and confusion?

The Scenario

Imagine you have multiple teams building different parts of an app, and they all need to share updates by sending messages to each other. Without a clear plan for what each message should look like, everyone guesses the format, causing confusion.

The Problem

When each team uses their own message style, it becomes slow and error-prone to understand or process events. Messages might miss important details or have inconsistent data, leading to bugs and wasted time fixing misunderstandings.

The Solution

Event schema design sets clear rules for how messages should be structured. This makes it easy for all teams to create, read, and react to events correctly, reducing mistakes and speeding up communication.

Before vs After

✗ Before

sendMessage({user: 'Alice', data: 'Hello'})
sendMessage({name: 'Bob', msg: 'Hi'})

✓ After

sendEvent({type: 'UserMessage', userId: 'Alice', message: 'Hello'})
sendEvent({type: 'UserMessage', userId: 'Bob', message: 'Hi'})

What It Enables

With event schema design, systems can reliably understand and process messages, enabling smooth, scalable communication across services.

Real Life Example

In an online store, when a customer places an order, a well-designed event schema ensures the payment, inventory, and shipping services all receive consistent order details to act on without errors.

Key Takeaways

Manual message formats cause confusion and errors.

Event schema design creates clear, consistent message structures.

This improves communication and reduces bugs in microservices.

Practice

1. What is the main purpose of an event schema in microservices?

easy

A. To define the structure and content of messages exchanged between services

B. To store user data in a database

C. To create user interfaces for microservices

D. To manage network connections between services

Solution

1. Step 1: Understand event schema role

   An event schema defines how messages look when services talk to each other.

2. Step 2: Identify correct purpose

   It ensures all services understand the message format and data.

3. Final Answer:

   To define the structure and content of messages exchanged between services -> Option A

4. Quick Check:

   Event schema = message format [OK]

Hint: Event schema = message format for services [OK]

Common Mistakes:

• Confusing event schema with database storage
• Thinking event schema manages UI or network
• Assuming event schema is about service deployment

2. Which of the following is a correct JSON snippet for an event schema with type and timestamp?

easy

A. {eventType: "OrderCreated", "timestamp": "2024-06-01T12:00:00Z"}

B. {"eventType": OrderCreated, "timestamp": 2024-06-01T12:00:00Z}

C. {"eventType": "OrderCreated", timestamp: "2024-06-01T12:00:00Z"}

D. {"eventType": "OrderCreated", "timestamp": "2024-06-01T12:00:00Z"}

Solution

1. Step 1: Check JSON syntax rules

   Keys and string values must be in double quotes; commas separate pairs.

2. Step 2: Validate each option

   {"eventType": "OrderCreated", "timestamp": "2024-06-01T12:00:00Z"} uses correct quotes and format; others miss quotes or have invalid syntax.

3. Final Answer:

   {"eventType": "OrderCreated", "timestamp": "2024-06-01T12:00:00Z"} -> Option D

4. Quick Check:

   Valid JSON = {"eventType": "OrderCreated", "timestamp": "2024-06-01T12:00:00Z"} [OK]

Hint: JSON keys and strings need double quotes [OK]

Common Mistakes:

• Missing quotes around keys or string values
• Using unquoted date/time strings
• Omitting commas between pairs

3. Given this event schema snippet:

{"eventType": "UserSignedUp", "timestamp": "2024-06-01T10:00:00Z", "data": {"userId": 123, "email": "[e-mail]"}}

What will be the value of data.email in the event?

medium

A. 123

B. "UserSignedUp"

C. "[e-mail]"

D. 2024-06-01T10:00:00Z

Solution

1. Step 1: Locate the data field in the event

   The event has a nested object under "data" with keys "userId" and "email".

2. Step 2: Identify the value of data.email

   The value for "email" is "[e-mail]" as a string.

3. Final Answer:

   "[e-mail]" -> Option C

4. Quick Check:

   data.email = "[e-mail]" [OK]

Hint: Look inside data object for email key [OK]

Common Mistakes:

• Confusing userId with email
• Picking eventType or timestamp instead
• Ignoring nested structure

4. Identify the error in this event schema:

{"eventType": "PaymentProcessed", "timestamp": "2024-06-01T15:00:00Z", "data": {"amount": 100, "currency": USD}}

medium

A. Missing comma after amount key

B. Missing quotes around the currency value USD

C. timestamp format is incorrect

D. eventType should be lowercase

Solution

1. Step 1: Check JSON value types

   String values must be in double quotes; USD is unquoted here.

2. Step 2: Verify other parts

   Comma after amount is present, timestamp format is ISO standard, eventType case is allowed.

3. Final Answer:

   Missing quotes around the currency value USD -> Option B

4. Quick Check:

   Strings need quotes [OK]

Hint: String values must have quotes in JSON [OK]

Common Mistakes:

• Ignoring missing quotes on string values
• Thinking timestamp format is wrong
• Assuming key case matters in JSON

5. You want to design an event schema for a microservice that sends user profile updates. Which design choice improves schema flexibility for future changes?

hard

A. Include a 'metadata' field to hold optional extra info

B. Fix the schema to only allow 'name' and 'email' fields

C. Use a flat schema without nested objects

D. Exclude timestamps to reduce message size

Solution

1. Step 1: Understand schema flexibility needs

   Flexible schemas allow adding new info without breaking existing services.

2. Step 2: Evaluate options for flexibility

   Adding a 'metadata' field lets you add optional data later safely.

3. Final Answer:

   Include a 'metadata' field to hold optional extra info -> Option A

4. Quick Check:

   Optional metadata = flexible schema [OK]

Hint: Add metadata field for optional future data [OK]

Common Mistakes:

• Fixing schema too rigidly limits future changes
• Removing timestamps loses event timing info
• Avoiding nested objects reduces clarity