Design a centralized Copy Service with versioning, segmentation, and experiments
This tests separation of editorial workflow from runtime delivery. A strong answer covers immutable versioned records, a resolution API evaluating segmentation rules, and delegating experiment bucketing externally.
What's really being asked
your ability to separate editorial state machines from high-scale runtime resolution. Interviewers want to see a data model that treats copy as immutable content with audit-friendly versioning, segmentation that is data-driven rather than hardcoded, and an API contract that keeps experiment bucketing outside the service boundary.
The full answer
four layers in order. First, the data model: a Copy table holds metadata (copy_id, name, channel) while CopyVersion stores immutable snapshots (version_id, copy_id, locale, content_json, author_id, created_at, status). SegmentationRules live in their own table (rule_id, dimensions_json, priority, target_version_id) so marketers can add geo or behavior filters without deployments. Second, the API surface: a management API for editors (POST /copies, POST /copies/{id}/versions, PUT /copies/{id}/versions/{vid}/publish) and a runtime resolution API (GET /resolve?locale=XX&segment_keys=...) that evaluates rules by priority and returns exactly one variant. Third, experimentation integration: the Copy Service accepts an optional experiment_id in the resolution request, calls the experimentation platform to retrieve the assigned variant bucket, and maps that bucket to a CopyVersion. The service never computes random assignment itself; it only stores the variant-to-copy mapping. Fourth, performance: edge caching keyed by a stable hash of locale plus resolved segment plus experiment salt, with cache invalidation triggered on publish events via a message bus.
The mistakes people make
storing copy as a single mutable row and overwriting it on each edit, which destroys history and rollback ability. Hardcoding segmentation logic like if country equals US in application code instead of making it configuration-driven. Embedding experiment randomization logic inside the Copy Service, which couples two domains that should evolve independently. Using a single table that mixes drafts and published content without status isolation, leading to race conditions in production reads.
What usually comes next
how do you resolve segmentation rules in under ten milliseconds when there are thousands of active rules (answer: pre-index dimension hashes, use a decision tree, or cache rule sets per channel). How do you roll out a new copy version atomically across fifty downstream services (answer: publish a new version ID, let services poll or receive an event, and keep a short TTL on cached resolutions). How do you handle concurrent edits from multiple copywriters (answer: optimistic locking on the version row or a git-like branch and merge workflow with required approvals).
A concrete example
a promotional banner for a holiday sale. The Copy record is holiday_banner_2024. CopyVersion v1 says Early Access and v2 says Flash Sale. A SegmentationRule maps US mobile users to v1 with priority 100. An experimentation platform overrides ten percent of US traffic to v2 via an experiment_id passed to GET /resolve. The service asks the experimentation platform for the users bucket, falls back to standard segmentation if no experiment is active, returns the chosen content with a Cache-Control header keyed by segment hash plus experiment salt, and invalidates the CDN when v3 is published.
Interview question
Which approach to A/B test bucketing maintains proper separation between the Copy Service and the experimentation platform?
- a.The service hashes the request context locally to assign a random variant bucket and then selects the matching CopyVersion
- b.The service passes the experiment_id to the external platform and maps the returned bucket to the correct CopyVersionCorrect
- c.The service caches experiment assignments at the edge for the test duration to avoid external bucketing calls
- d.The service adds experiment criteria to the SegmentationRules table and evaluates them as part of rule resolution
Why? this is the answer
The card specifies that the Copy Service must never compute random assignment itself; it delegates bucketing to the external platform and only stores the variant-to-copy mapping. Option A is a tempting distractor because embedding randomization logic inside the service is explicitly listed as a common wrong answer that couples two domains that should evolve independently.
Just read this? Test yourself on what you have been reading.
Read the original → rannlab.com
- #system design
- #microservices
- #content management
- #api design
- #experimentation
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 system design — each one lists the topics its interview covers.
See open roles