Event schema design in Microservices - Scalability & System Analysis

Scalability Analysis - Event schema design

Growth Table: Event Schema Design at Different Scales

Users/Events	100 Users	10K Users	1M Users	100M Users
Event Volume	~1K events/sec	~100K events/sec	~10M events/sec	~1B events/sec
Schema Complexity	Simple, few fields	Moderate, versioning starts	Complex, strict versioning & validation	Highly optimized, schema registry mandatory
Schema Evolution	Manual updates	Automated backward/forward compatibility checks	Automated schema registry with compatibility enforcement	Multi-region schema replication and governance
Event Size	Small payloads	Payload size optimization needed	Payload compression and schema pruning	Strict payload limits and binary encoding
Validation	Basic validation	Schema validation on producer side	Validation on producer and consumer sides	Centralized validation service with monitoring
Storage	Local or small cluster	Distributed event store	Partitioned, sharded event storage	Geo-distributed storage with tiering

First Bottleneck

The first bottleneck is the event schema validation and compatibility management. As event volume grows, ensuring all producers and consumers agree on the schema becomes challenging. Without strict schema governance, incompatible changes cause failures and data loss.

Scaling Solutions

• Schema Registry: Use a centralized schema registry to manage versions and enforce compatibility rules.
• Backward and Forward Compatibility: Design schemas to allow old and new versions to coexist without breaking consumers.
• Schema Evolution Policies: Define clear rules for adding/removing fields, default values, and deprecations.
• Payload Optimization: Use compact formats like Avro or Protobuf and compress payloads to reduce size and bandwidth.
• Validation at Edge: Validate events at producer side to catch errors early and reduce invalid data flow.
• Partitioning and Sharding: Distribute event storage and processing to handle high throughput.
• Monitoring and Alerting: Track schema usage and validation errors to detect issues quickly.

Back-of-Envelope Cost Analysis

• At 10K users generating ~100K events/sec, expect ~10-50 MB/s network bandwidth depending on event size.
• Storage needs grow with event retention; 1M events/sec with 1KB payload = ~86 TB/day raw data.
• Schema registry and validation services require low latency and high availability; plan for multiple instances.
• Compression and efficient encoding reduce bandwidth and storage costs significantly.

Interview Tip

When discussing event schema design scalability, start by explaining schema versioning and compatibility challenges. Then describe how a schema registry helps manage changes safely. Highlight the importance of validation and payload optimization. Finally, discuss how partitioning and monitoring support scaling to millions of events.

Self Check

Your schema registry handles 1000 QPS validation requests. Traffic grows 10x. What do you do first?

Answer: Scale the schema registry horizontally by adding more instances behind a load balancer to handle increased validation requests and ensure low latency.

Key Result

Event schema design first breaks at schema validation and compatibility management as event volume grows. Using a centralized schema registry with strict versioning and validation is key to scaling safely.

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