Design a cross-product user journey data architecture
This tests portfolio-scale data platform design. A strong answer outlines streaming event ingestion, a unified identity graph, consent-aware PII vaults, and schema registries with data contracts.
What's really being asked
This question evaluates your ability to design a Customer Data Platform that aggregates and organizes customer data from independently developed products to build unified user profiles without creating tight coupling or privacy violations. The interviewer cares about separation of concerns between data producers and consumers, handling identity across disconnected login systems, and governing PII under regulations like GDPR and CCPA. Success requires balancing centralization with product autonomy.
The full answer
First, an ingestion layer using lightweight SDKs or API gateways that emit standardized event schemas into a streaming bus like Kafka or Kinesis, keeping product teams decoupled from downstream systems. Second, a central data lake or lakehouse that stores raw events in open formats like Parquet or Iceberg, enabling both batch and real-time analytics. Third, an identity resolution service that maintains an ID graph mapping anonymous IDs, device IDs, and authenticated user IDs using deterministic stitching where possible and probabilistic matching as a fallback, with clear merge and unmerge rules. Fourth, a privacy architecture that isolates PII in encrypted vaults, attaches consent tokens to every event, and propagates deletion requests back to source products via tombstoning or hard deletes. Fifth, schema governance through a central registry with versioning, backward compatibility checks, and data contracts so independent product teams can evolve their telemetry without breaking the analytics pipeline.
The mistakes people make
Proposing a single shared relational database across all products immediately signals a lack of distributed systems experience. Treating identity resolution as a simple SQL join on email address ignores cross-device behavior and data quality issues. Suggesting that privacy can be handled later in a data warehouse layer fails compliance requirements because raw logs often contain PII. Recommending a rigid global schema forces every product team into a bottleneck, killing adoption.
What usually comes next
How would you handle a user requesting deletion across fifty microservices? What happens when two products disagree on whether two user records represent the same person? How do you maintain analytics uptime when a product team deploys a breaking schema change? What is your latency budget for real-time journey analytics versus backfill processing?
A concrete example
Imagine a user browses Product A anonymously on mobile, then logs into Product B on desktop with the same email. Your ingestion pipeline captures both event streams. The identity graph detects the shared email and creates a unified profile, but only after consent is verified in both product privacy vaults. When the user later requests deletion, the vault orchestrates deletion commands back to both product event stores and removes the stitched graph edges, leaving aggregated analytics intact but scrubbing personal identifiers.
Interview question
How should the platform handle a user deletion request across fifty independently deployed microservices while keeping aggregated analytics intact?
- a.Orchestrate deletion commands to each product store and remove identity graph edges while preserving aggregated metricsCorrect
- b.Scrub PII from streaming bus topics and wait for the next compaction cycle to propagate changes
- c.Tombstone the user record in the identity graph and rely on the schema registry to notify microservices
- d.Execute cascading hard deletes in the central data lake and replay all downstream aggregates
Why? this is the answer
The card's concrete example states that the privacy vault orchestrates deletion commands back to source product stores and removes stitched graph edges, leaving aggregated analytics intact. Option D is tempting but wrong because deleting only in the central lake fails to reach independent source systems, and C mistakenly assigns deletion propagation to the schema registry rather than the privacy vault.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #data architecture
- #system design
- #privacy
- #identity resolution
- #schema evolution
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on data architecture — each one lists the topics its interview covers.
See open roles