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.