Digital commerce — consumer super-app

Integration Architecture for a Consumer Super-App

A super-app has to make many independent brand platforms behave like one product: single identity, one loyalty balance, one payment rail, one view of the customer. We designed the integration architecture that binds them — an API and enhancement layer over the brand platforms, three deliberately different integration patterns, and a data platform that turns the whole estate into one customer view.

Client
Indian conglomerate — consumer digital business
Role
Enterprise architect — integration and data architecture
Period
2021-01

The challenge

A super-app is an integration problem wearing a product's clothes. Each brand runs its own commerce platform, catalogue, pricing and order management, all built independently and none of them expecting to be part of something larger. The customer, though, expects one login, one loyalty balance, one payment method and one order history. Doing that by wiring brand systems directly to each other produces a mesh that nobody can operate and that gets more expensive with every brand added. The architecture also has to serve two very different clocks: a payment authorisation measured in milliseconds, and a nightly catalogue reconciliation measured in gigabytes.

Approach

  • Put an API and enhancement layer between the brand platforms and the shared services, so neither side depends on the other's internals.
  • Fronted everything with a single gateway carrying WAF, so security and traffic policy live in one place rather than per brand.
  • Adopted three integration patterns deliberately — event-based streaming, real-time API, and scheduled file — and matched each flow to the one that fits its latency and volume.
  • Made identity, loyalty, offers and payments shared services consumed by every brand, rather than replicating them per brand.
  • Routed operational data into a data platform layered lake → warehouse → customer 360, so analytics did not become another integration mesh.
  • Kept bulk and near-real-time paths separate: file-based loads for initial and periodic bulk, streaming for anything the customer sees.

Innovation

  • Treated 'which integration pattern' as a per-flow decision with explicit criteria, rather than a platform-wide standard. Standardising on one pattern is how super-app integrations become either slow or unaffordable.
  • Used an enhancement layer to buy independence in both directions — brands keep shipping on their own cadence, shared services evolve without brand releases.
  • Separated the customer-facing path from the analytical path early, so the data platform consumes the estate rather than adding to it.

Outcome

  • Integration architecture defined across brand platforms, shared services and the data estate.
  • Shared identity, loyalty, offers and payments consumed consistently across brands.
  • Three integration patterns established with clear criteria for choosing between them.
  • Data platform designed to produce a single customer view rather than another feed mesh.

Recommendations

  • A super-app is an integration programme, not an app project. Budget and staff it that way.
  • Do not standardise on one integration pattern. Payment authorisation and nightly catalogue reconciliation have nothing in common but a network.
  • Put an enhancement layer between shared services and brand platforms. Direct coupling means every brand release becomes a platform release.
  • Centralise identity, loyalty and payments; leave catalogue and fulfilment with the brand. Getting this split wrong is the most expensive mistake available.
  • Design the data platform to consume the estate, not to join it. Analytics feeds that participate in operational integration become impossible to change.

Architecture

Super-app integration architecture: brand app and platform on the left, an API gateway with integrated WAF, a platform enhancement layer, shared services for identity, loyalty, offers, payments and personalisation, and a data platform with lake, warehouse and customer 360
The integration architecture. Brand app and platform (left) reach shared services only through a gateway and enhancement layer; the three integration patterns — event streaming, real-time API and scheduled file — are applied per flow; operational data lands in a platform layered lake → warehouse → customer 360. Service and host names are masked.

Technology

  • API gateway with integrated WAF
  • Event streaming
  • Near real-time and batch integration
  • Single sign-on / identity federation
  • Loyalty and offer engines
  • Dremio
  • Data lake / warehouse / customer 360

Want the working artefacts?

The account above is the whole story. If you want the material behind it — data models and partitioning, sizing inputs, load-test design, the decision frameworks as something you can actually apply — we will send the appendix for Integration Architecture for a Consumer Super-App to a work address. Client identities stay masked either way.

Facing something similar?

If any of this maps onto a problem you are carrying, we are happy to talk it through — no obligation, and you will get a straight answer about whether it is worth doing.

Start a conversation