Skip to main content
Adrià García

Patterns from production

Architecture Patterns

Short, visual notes on customer-data decisions that become expensive once a CDP reaches production.

Map of the patterns

Each pattern sits where the problem shows up. The three in the band have no stage because they cross all of them.

Map of the eleven architecture patterns over the customer data journey, in four stages plus a foundation band. First stage, identity, with two patterns: 01, split profiles, on identity as a contract with the source, and below it 08, people who do not add up, on the person you measure versus the person you activate. Second stage, profile and state, with three: 02, one object for all, on separating operational state from customer state; 03, writes that collide, on Profile writes as shared state; and 10, everything in Profile, on what goes into Profile and what stays in the data lake. Third stage, decision: pattern 06, duplicated eligibility, on modelling Decisioning inputs by consumption. Fourth stage, activation, with two: 05, every channel from zero, on reusing the data foundation across channels, and below it 11, another brand as sender, on the brand as a relationship rather than a person attribute. Below them, a foundation band crossing all four stages holds the three patterns that belong to no single stage: 04, temporary stays, on the exit path an MVP architecture needs; 07, only you can run it, on handover as architecture; and 09, a no that is not enforced, on consent as a chain. Each cell links to its page, and the full list with the long titles sits right below the map.

11 patterns

Identity → Operations
  1. Customer state

    Separate operational state from customer state

    Immediate orchestration and queryable facts do not need the same representation.

    Read pattern →
  2. Profile governance

    Profile writes are shared-state engineering

    Multiple writers turn the profile into shared operational state.

    Read pattern →
  3. Delivery

    MVP architecture needs an exit path

    Starting narrow is valid. Making temporary choices permanent by accident is not.

    Read pattern →
  4. Channels

    Reuse the data foundation across channels

    Add channels by reusing customer and decision foundations, not rebuilding them.

    Read pattern →
  5. Decisioning

    Model Decisioning inputs by consumption

    Decision inputs have different lifecycles, and they do not all belong in the profile.

    Read pattern →
  6. Operations

    Handover is architecture

    An architecture is not complete until someone else can operate it.

    Read pattern →
  7. Identity

    The person you measure is not the person you activate

    The identity graph decides whom to activate now. Analytics stitching rebuilds who it was. They are two answers, and each is designed on its own.

    Read pattern →
  8. Consent

    Consent is a chain, not a field

    It is decided in the CMP, travels through the SDK, is stored in the profile and enforced by each destination. It breaks at the link nobody designed.

    Read pattern →
  9. Profile and retention

    Profile is for activation; the data lake is for memory

    What goes into Profile and how long it stays is an architecture decision. It also decides what counts towards the licence.

    Read pattern →
  10. Multi-brand activation

    A brand is a relationship, not a person attribute

    In a multi-brand group, a main brand does not describe all of a person's relationships. Each send needs a brand and the relevant permission check.

    Read pattern →

Architecture lens

One consistent way to read architecture

Every pattern answers the same five questions before recommending a solution.

  1. 01What breaks
  2. 02Where the state lives
  3. 03Who owns it
  4. 04What trade-off we accept
  5. 05How it evolves