Store, Merchant, and Omnichannel Architecture
The project established a consistent model for stores, merchants, suppliers, and service areas so that the website, app, operations tools, and external APIs followed the same business rules.
I worked on the design and evolution of this area between 2020 and 2022. It could look like a back office for maintaining store records, but one item of master data might affect product display, store search, home delivery, supplier management, and operational decisions.
Company names and internal rules have been removed. The examples below explain what I contributed.
Domain boundaries
People often use “store,” “merchant,” “supplier,” and “counter” loosely in conversation. In software, they are different objects.
One merchant may operate several stores. A store can have multiple counters and service areas. A supplier has its own contracts and lifecycle. If the system reuses one identifier for convenience, it can grant the wrong access, connect the wrong data, or close an entire merchant when only one store should close.
My first important contribution was to clarify the identity, relationship, lifecycle, and owner of each object and turn that understanding into a shared business model.
Role and key responsibilities
I was responsible for the architecture and continuing improvement of the relevant systems. Key responsibilities included:
- Clear business boundaries. I separated stores, merchants, suppliers, counters, and service areas and defined how they related, who maintained them, and when they became active or inactive.
- One set of rules for every channel. Validation, permission, and state rules that had been repeated in Web and API controllers moved into shared services used by administration pages, APIs, batch jobs, and repair tools.
- A stronger location and service-area capability. I brought coordinates, administrative regions, delivery radii, polygons, and opening status into one explainable decision process.
- Safer bulk change and repair. Large changes started with a preview and impact estimate, then ran in bounded batches with checkpoints and before-and-after checks.
- Controlled human intervention. Urgent operational changes gained permissions, reasons, expiry times, and audit history, allowing fast correction without silently bypassing the platform's rules.
This changed a collection of separate features into reusable platform capabilities on which later work could build.
Service-area decision example
When a customer enters an address, the system cannot simply choose the nearest store. It must consider the administrative area, whether the store is open, whether its delivery area covers the address, and whether a temporary operational override exists.
If the website, app, and operations tool each implement that decision separately, the same address can receive different answers.
The decision moved into a common service. Channels supplied the address and business context; the service returned eligible stores and recorded which rules were applied. Operations could then distinguish bad coordinates, incorrect configuration, and intended business behaviour during an investigation.
Safe control of bulk data changes
Store data often needed bulk import or repair. A script with the wrong condition could affect thousands of records at once.
I treated repair scripts as controlled software. A dry run first showed the number and examples of records that would change. Real execution used small batches and progress checkpoints, followed by checks of the important data. A failed run could resume safely and had a rollback or compensation path.
The main value was to replace operations that depended on individual caution with a controlled and repeatable team process.
Outcome and architecture value
The result was clearer store and merchant data, more consistent behaviour across channels, more explainable location decisions, and safer bulk operations.
Rules that several systems had each written separately were pulled into shared services, with a controlled way left open for operations teams to inspect and correct results.
The resulting architecture uses common rules to maintain consistency while preserving an explicit and controlled path for necessary business exceptions.