Event schema design in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Event Schema Versioning

In event-driven microservices, why is it important to version event schemas?

A To ensure backward compatibility when event structure changes

B To limit the number of events a service can produce

C To encrypt event data for security purposes

D To reduce the size of events for faster transmission

💡 Hint

Think about what happens when event consumers expect a certain format but producers change it.

Versioning event schemas allows services to evolve independently without breaking consumers that rely on older event formats.

❓ query_result

intermediate

Identify the Correct Event Schema Output

Given this JSON event schema for a user registration event, which option correctly represents a valid event instance?

{
  "eventType": "UserRegistered",
  "version": 2,
  "payload": {
    "userId": "12345",
    "email": "[e-mail]",
    "timestamp": "2024-06-01T12:00:00Z"
  }
}

A {"eventType": "UserRegistered", "version": 2, "payload": {"userId": "12345", "email": "[e-mail]", "time": "2024-06-01T12:00:00Z"}}

B {"eventType": "UserRegistered", "version": 2, "payload": {"userId": "12345", "email": "[e-mail]", "timestamp": "2024-06-01T12:00:00Z"}}

C {"eventType": "UserRegistered", "version": "two", "payload": {"userId": "12345", "email": "[e-mail]", "timestamp": "2024-06-01T12:00:00Z"}}

D {"eventType": "UserRegistered", "payload": {"userId": 12345, "email": "[e-mail]"}}

💡 Hint

Check for correct data types and required fields matching the schema.

Option B matches the schema exactly with correct field names and types. Others have missing or wrong fields or types.

🧠 Conceptual

advanced

Detect Schema Definition Syntax Error

Which option contains a syntax error in this Avro event schema snippet?

{
  "type": "record",
  "name": "OrderPlaced",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "items", "type": {"type": "array", "items": "string"}}
  ]
}

A

{
  "type": "record",
  "name": "OrderPlaced",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "items", "type": {"type": "array", "items": "string"}
  ]
}

B

{
  "type": "record",
  "name": "OrderPlaced",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "items", "type": {"type": "array", "items": "string"}}
  ]
}

C

}
]  
}}"gnirts" :"smeti" ,"yarra" :"epyt"{ :"epyt" ,"smeti" :"eman"{    
,}"elbuod" :"epyt" ,"tnuoma" :"eman"{    
,}"gnirts" :"epyt" ,"dIredro" :"eman"{    
[ :"sdleif"  
,"decalPredrO" :"eman"  
,"drocer" :"epyt"  
{

D

{
  "type": "record",
  "name": "OrderPlaced",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "items", "type": "array", "items": "string"}
  ]
}

💡 Hint

Look for missing brackets or commas in JSON structure.

Option A is missing a closing brace for the 'items' field type object, causing a syntax error.

❓ optimization

advanced

Optimizing Event Schema for Size

You want to reduce the size of your event messages without losing essential information. Which schema design choice helps achieve this?

A Use verbose nested objects for clarity

B Include all possible fields with default values even if unused

C Use shorter field names and optional fields for rarely used data

D Add redundant fields to improve data integrity

💡 Hint

Think about what makes data smaller to send over the network.

Shorter field names and optional fields reduce message size by omitting unnecessary data and minimizing text length.

🔍 Analysis

expert

Identify the Cause of Event Consumer Failure

An event consumer fails to process events after a schema update. The new schema added a required field without a default value. What is the most likely cause?

A The event topic name was changed without updating the consumer

B The producer is sending events with extra fields ignored by the consumer

C The consumer has outdated credentials to access the event stream

D The consumer expects the new required field but old events lack it, causing deserialization errors

💡 Hint

Consider what happens when required data is missing in older events.

Adding a required field without a default breaks backward compatibility because older events don't have that field, causing consumer errors.

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