Skip to content

CONCEPT Cited by 1 source

Market Group (country-level isolation)

Definition

A Market Group is a named deployment instance of a serving API that owns a subset of the geographic markets (countries) the platform serves. It is a blast-radius containment primitive: multiple Market Groups run the same serving code on disjoint country subsets, with a routing layer that can shift traffic between groups independently of the application.

The term is Zalando-originated, from the PRAPI write-up:

"To achieve a level of country-level isolation, multiple instances of PRAPI are deployed—known as Market Groups— with each serving a subset of our countries. Routing configuration allows us to dynamically shift traffic between Market Groups, allowing us to isolate internal or canary test traffic from high-value country traffic." (Source: .)

Market Group is a specific, geography-axis instance of the more general cell-based architecture pattern.

Why the geography axis specifically

  • Customer-experience homogeneity within a country. Pricing, stock catalogue, tax, language, legal requirements are country-scoped; keeping each country's traffic in a dedicated serving instance means failures, bad deploys, and load spikes stay bounded within their market.
  • Independent failure domains. A DynamoDB hot-partition event, a poisoned Kafka offset, or a bad config push that lands on one Market Group cannot fan out across the whole platform.
  • Traffic-shift as a canary primitive. New versions can be deployed to a low-value Market Group (e.g. a small country or an internal-test group) first; the routing layer ramps traffic to it before touching high-value groups.
  • Independent scaling. Cyber Week traffic in DACH vs. Nordic markets scales differently — Market Groups scale their Updaters, serving pods, and DynamoDB capacity independently.
  • Fast cold-fill. Bringing up a new Market Group bottlenecks on DynamoDB write capacity (adjustable in minutes), not on the serving-cluster bootstrap time.

What Market Groups don't do

  • They are not a sharding key. Within a Market Group, product data is still hashed across pods (e.g. via CHLB). Market Groups partition the deployment, not the dataset.
  • They are not a region. A Market Group is a country- subset label applied to a deployment in a single (potentially multi-AZ) region; multi-region failover is orthogonal.
  • They do not by themselves guarantee per-country data residency — the underlying DynamoDB may still span regions unless the Market Group is also data-region- locked.

Seen in

  • — PRAPI's canonical instance. Each Market Group's Updaters scale horizontally up to the source-stream partition count.
  • sources/2025-12-16-zalando-the-day-our-own-queries-dosed-us-inside-zalando-search — canonical wiki instance of market isolation at the Elasticsearch storage tier during an incident. Zalando's Search & Browse team discovered during a self-inflicted-DoS incident that all market-group ES clusters stayed healthy except the one co-tenanting two of their largest markets; steady-state market-group isolation held as designed. The live mitigation was to split the two co-tenant markets into separate clusters via node.attr.market allocation filters — an incident-time instance of the same blast-radius containment primitive operating on ES shard placement instead of serving-API routing. See patterns/split-cluster-by-market-for-load-isolation.
Last updated · 542 distilled / 1,571 read