PATTERN Cited by 1 source

Fallback rule for experience / context conflict¶

Problem¶

When selection metadata is used to match a request to exactly one Experience (or, more generally, to pick a single presentation context), ambiguity is unavoidable. Real customer intent doesn't always point at one Experience:

A search for "Nike Adidas" matches two brand Experiences.
A catalog browse with two brand filters applied matches two Experiences.
A marketplace page mixes retailers each of whom has their own elevated Experience.

The question: which Experience wins? And if the answer is "none of them", what does the page look like?

Naive options fail:

Priority ordering — any deterministic rule (alphabetical, most-recent, most-selective) produces a winner, but each brand is a counterparty with contractual expectations; arbitrary priority breaks those silently.
Policy merging — policies like THEME have no sensible merge semantics. Taking the union / intersection of two brands' theme values produces incoherent visuals.
No-context default — works, but pushes the "what does default look like" knowledge into every downstream backend as branching logic.

Solution¶

When multiple contexts match, don't try to pick or merge — resolve to a named fallback context. The fallback is a first-class Experience containing the neutral / default policies the rest of the system expects. Zalando's own framing: "How to decide which experience to choose when two brands belong to different experiences? Thinking about the right use cases to support the business needs, whilst keeping simplicity is the key. Our approach to solving some cases is to define Fallback experiences, to be able to catch these use-cases" (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando).

See concepts/fallback-experience for the concept; this pattern is the how-to-apply-it companion.

Shape¶

   selection rules match → N candidates
                             │
              ┌──────────────┴──────────────┐
              │                             │
        N == 1                          N != 1
              │                             │
      pick that                     pick the fallback
       Experience                    Experience (a named,
                                     explicit Experience)

Invariants¶

The fallback is an explicit Experience object. It has its own Policies, its own name, its own (possibly empty) selection-metadata. Downstream backends apply its policies identically to any other Experience; there is no "if no Experience" branch in the backend.
Policy coherence is preserved. Every request resolves to exactly one Experience's policies — never a merged mix-up that produces inconsistent UI.
Fallback is named, not hardcoded. Editable as data so the neutral presentation can evolve without code changes in downstream backends.
Single code path in backends. Backends always apply the policies of the Experience they receive; there is no distinction between "matched an Experience" and "fell back".

Trade-offs¶

Pros:

Preserves policy coherence (no merge-induced incoherence).
Keeps downstream backends stateless about match success — every request has a named Experience.
Evolvable: the fallback's policies can be adjusted centrally.
Safe for contractual brand relationships — no arbitrary priority decision is made on the brand's behalf.

Cons / risks:

The fallback's behaviour must itself be coherent and desirable for ambiguous cases. Badly chosen fallback policies mean all ambiguous cases look bad.
Silent fallback — an operator can't tell from downstream logs whether a request was a confident match or a fallback without explicit instrumentation. Suggests emitting a metric counting fallbacks per Experience-candidate pair for tuning.
Some cases should have a specific winner (e.g. one brand explicitly prioritised via contract); falling back silently can mask missing priority rules.

When to use¶

Multiple named contexts can match the same request, and merging their policies is semantically meaningless.
The "no named match" case has well-defined desired behaviour that generalises across all ambiguous cases (Zalando's case: consistent grey-packshot catalog view).
The counterparties of individual contexts are external stakeholders (brands, partners) whose trust would be damaged by arbitrary priority ordering.

When not to use¶

One of the matching contexts legitimately has priority (e.g. paid-placement campaigns must always win over organic brand elevation). Encode that priority explicitly; don't hide it behind a fallback.
The merge is meaningful — e.g. intersecting two feature-flag sets is fine in some domains.
Very few Experiences → plain enumeration of pairwise rules may be simpler than a fallback.

Implementation notes¶

Emit a metric (Experience candidates × resolved-to-fallback boolean) so it's possible to see which brand pairs are co-matching often. Frequent pair-conflict is a signal to negotiate priority with the brands or narrow the selection metadata.
Keep the fallback's Policies aligned with the "Zalando default" presentation so designers / merchandising can diff an Experience against the fallback to see exactly what it's changing.
Treat the fallback as itself evolvable: A/B-testable, per- market customisable if markets have different neutral defaults.

Seen in¶

sources/2023-06-25-zalando-context-based-experience-in-zalando — canonical introduction of the pattern in Zalando's IF Experience mechanism.