Design a centralized Copy Service with versioning, segmentation, and experiments

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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).

ONE 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.