tezvyn:

Design analytics event schema validation

AI-drafted, machine-checkedSource: interviewintermediate
WHAT IT TESTS

protecting data quality at scale.

OUTLINE

define a schema registry, validate at both client (fast feedback) and server (authoritative gate), and quarantine failures to a dead-letter store.

WHAT THIS TESTS The interviewer wants a pragmatic design that prevents garbage events from polluting analytics, while staying resilient to old clients, bugs, and evolving requirements.

A GOOD ANSWER COVERS Start with a single source of truth: a versioned schema registry that declares, per event type, the required properties, their types, and constraints. For enforcement, argue for both layers. Client-side validation gives developers immediate feedback and catches mistakes before data is sent, but you cannot rely on it alone because clients can be stale, offline-cached, or tampered with. The server is the authoritative gate that every event must pass before landing in the warehouse. On failure, never silently drop the event, because silent loss hides bugs; instead route invalid events to a dead-letter queue or quarantine table along with the validation error and the offending payload, so the data team can investigate, fix the producer, and potentially replay. Add monitoring that alerts when the failure rate spikes, signaling a broken release.

COMMON WRONG ANSWERS Validating only on the client and trusting it, silently discarding failures so bad releases go unnoticed, rejecting events so strictly that a minor extra field loses otherwise-good data, or having no versioning so any schema change breaks older clients.

LIKELY FOLLOW-UPS How do you evolve a schema without breaking older app versions still in the field? Strict reject versus tolerant accept-and-flag, when to choose each? How do you handle high-volume validation performance? How do you replay corrected dead-letter events?

ONE CONCRETE EXAMPLE A new app release ships a purchase event missing the required amount field. Client checks were skipped due to a bug, so the server validator catches it, routes those events to a dead-letter store tagged missing_required_field, and an alert fires as the failure rate jumps. The warehouse stays clean, the team patches the client, and the quarantined events can be repaired and replayed.

Read the original → twilio.com

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.