Retail — online marketplace

An Orchestration Layer for a Marketplace That Cannot Go Offline

Built the marketplace's integration orchestration layer on Apache NiFi with an event backbone underneath it, moved stock and price into near real-time search synchronisation, and delivered clustering and index-estate work on a platform that trades continuously.

Client
Top-3 Indian fashion & lifestyle marketplace
Role
Enterprise architect — integration orchestration, search platform and platform scalability
Period
2017-01 – 2019-10

The challenge

A marketplace integrates constantly — sellers, catalogue, pricing, stock, orders, fulfilment — and the connections tend to accumulate as point-to-point jobs, each with its own schedule, error handling and owner. Stock and price reached the search index on a batch cadence, so the storefront could show items as available at prices that had already changed. Meanwhile the platform itself needed structural work: a clustered order-management topology, and a production index estate that had accreted over years of releases with no record of which indexes were deliberate. None of it could interrupt trading.

Approach

  • Established a single orchestration layer for integration flows, with an event backbone beneath it, replacing scattered point-to-point jobs.
  • Introduced schema governance so producers and consumers could evolve without breaking each other.
  • Moved stock and price onto near real-time synchronisation into search, rather than a batch cadence.
  • Classified every production index by origin before proposing changes, so the discussion concerned a known estate rather than a guess.
  • Broke the clustering programme into independently shippable sub-activities with their own environments and acceptance criteria.
  • Wrote release notes at a level the systems integrator's build team could execute without the architect present.

Innovation

  • Treated integration as a platform with its own operability requirements, rather than as a set of jobs owned by whoever wrote them.
  • Made configuration capture the deliverable — the durable outcome was that the estate became reviewable, not merely faster.
  • Designed each change to be shippable on its own, so a slip in one workstream did not hold the others.

Outcome

  • Integration orchestration layer established as the standard route for new flows.
  • Stock and price synchronised into search in near real time, replacing batch propagation.
  • Order-management tier moved to a clustered topology without a trading interruption.
  • Production index estate classified, captured in configuration and brought under review.
  • Subsequent releases taken up by the client's integrator team using the documented procedures.

Recommendations

  • Point-to-point integration is cheap to add and expensive to own. The cost shows up as operational load, not as project cost.
  • Batch-synchronised stock and price is a customer-experience problem before it is a technical one — customers meet the staleness, not you.
  • Classify before you optimise. An index estate nobody can explain is a change-management problem before it is a performance one.
  • Write release notes for the team that will run them, not for the person who wrote the change.
  • On a platform that cannot go offline, shippable increments beat a well-planned big-bang cutover every time.

Architecture

NiFi flow: GetFile to UpdateAttribute to ConvertRecord CSV-to-Avro to PublishKafkaRecord
A slice of the ingestion pipeline in the orchestration layer: files picked up, tagged with a schema, converted CSV-to-Avro and published to Kafka as records. The production template runs 83 processors in this style.
Latency and reliable-communication solution diagram
Latency and reliable-communication design for the marketplace integration estate.

In their words

Great effort holding fort during crucial stages of the project go-live.

Delivery leadership, platform vendor · 2016-09

Technology

  • Apache NiFi
  • Apache Kafka
  • Schema Registry
  • Apache SOLR / SOLR Cloud
  • SAP Commerce (hybris)
  • Order Management

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 An Orchestration Layer for a Marketplace That Cannot Go Offline 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