Merit · Engineering onboarding · Internal
Two teams run the live system. Aditya's Marketplace team builds one shop per client. Akshay's Platform Services team builds the machines every shop calls. A third stack, the E-Commerce Solution, is being built to absorb both. This page is diagrams: where each part sits, how work moves between them, and exactly which behaviour the new stack still cannot do.
How much of this is documented fact, and how much is reconstruction.
Confluence carries a page named "Application Architecture" for Marketplaces, MGC, Peoppl, RewardsBy, GiftcardsBy, GiftiGlobal, LMS, Content API, Communication Service and Identity Service. Nearly all are unfilled C4 templates. Several say "To be Filled". The Points Exchange one says "lorem ipsum". The Email Service page has an empty body. An empty page is not a simple system.
So these diagrams were rebuilt from the places that do carry current truth: the Platform Sprint Backlog Review pages, the Saudia storefront RFCs, live Jira ticket bodies, the infrastructure and database pages, and Merit's product documentation. No source code was read. Where a diagram shows a dashed arrow, that path is agreed but not built.
Aditya Sanka. The shops. Jira MP.
Akshay Chennupati. The machines. Jira MPS.
Muneeb Meer leads engineering, Khawar Rasheed is PM, built with Tintash. The replacement stack, and the owner of OMS. Jira MSP and STOR.
Aditya's stack and Akshay's stack are both the Old World. They are two halves of one live production system, not two competing designs. The New World is a third stack beside them.
Al Fursan is moving to a different platform, not moving its code. Only data migrates: product data does not, sellers re-upload their catalogue into PIM through the Seller Portal instead. The migration is done when Al Fursan runs entirely on the E-Commerce Solution and the legacy system for Al Fursan is decommissioned.
Only Al Fursan moves. Agora, Taino Marketplace, DreamPoints and the Legacy Shops stay on the Old World.
The rollout is a canary, not a shadow run. Real members transact on the new system in growing cohorts: Merit internal first, then a closed user group, then 5%, 25%, 50% and 100% of members. Each cohort's output is compared against legacy for parity, a member stays on whichever side they were first assigned to, and each cohort has its own kill switch back to legacy. Legacy stays warm as a fallback throughout.
The approach is develop the gaps: audit what legacy does, match it against what the New World already has, build whatever gap is missing, then take on new requirements. PIM replaces the Online Catalogue, and a Seller Portal admin role becomes the hub for operating physical orders.
MGC, the legacy commerce and shipping engine, is replaced for Al Fursan by the Fulfillment Service and TMS on OTO, except for gift cards: MGC stays as a supplier the Fulfillment Service calls. Point Exchange and Payout Service also stay on the Old World; the New World calls them rather than rebuilding them. It is not the same as retiring Platform Services. DPR and Communication stay live and in active development, with no deprecation planned. Do not read this page as "the violet band disappears".
Every part, and the twelve places work crosses from one part to another. Each numbered badge on the diagram is a seam listed underneath.
Twelve seams, numbered. Band 1 is one shop per client. Band 2 is the services every shop calls. The New World stack is a third band being built to absorb both.
Old World is two bands: one shop per client on top, one shared set of services underneath. New World is a single band where the shop, the catalog, the orders and the supply are parts of the same product. Migration is not rewriting a box. It is collapsing two bands into one.
This costs new joiners about two weeks. Read it once now.
| Word | Meaning A | Meaning B | How to tell |
|---|---|---|---|
| Storefront | A running client shop: Saudia, Nielsen, Kantar, MCM. Aditya. | The Storefront Admin Portal product, board STOR. E-Commerce Solution. | Names a client, meaning A. Says admin portal, template or tenant, meaning B. |
| Platform | Akshay's team and its services. | Loosely "the whole system", in exec conversation. | Platform is an Old World word. The new stack is called the E-Commerce Solution. |
| OMS | Platform's team page lists "order lifecycle infrastructure" among its components. | The OMS product, built by Muneeb Meer's team in the E-Commerce Solution. | Meaning B wins, and it is not Akshay's. OMS core and the state machine belong to Muneeb's team on the E-Commerce Solution side. Platform appears only as a consuming dependency, such as the order-status webhook into B2C. The Platform team page was never corrected and still misleads. |
| Catalog | Legacy Catalog and the Online Catalogue. Akshay's. | PIM plus E-commerce Core. | OC and MGC are always Old World words. |
Two Jira instances, four boards.
| Team | Lead | Board | Owns |
|---|---|---|---|
| Marketplace | Aditya Sanka | MP, merit-incentives | Saudia and Al Fursan, Nielsen, Kantar, Mastercard, Agora, demo marketplaces, checkout geocoding |
| Platform Services | Akshay Chennupati | MPS, merit-incentives | MGC, Merchandise Service, Online Catalogue, Points Exchange, Payout, Communication, DPR, Experience, SPL AWB |
| E-commerce Core and Seller Portal | Muneeb Meer, engineering. Khawar Rasheed, PM | MSP, tintash | PIM, E-commerce Core, OMS, Seller Portal, MGC legacy sync |
| Storefront product | Khawar Rasheed, PM | STOR, tintash | Storefront Admin Portal, template, tenant provisioning, basic CMS |
Scale check. The legacy boards MP and MPS carry roughly twenty times the issue history of the new-world boards MSP and STOR. That ratio is the honest measure of how much behaviour lives in the Old World and was never written down anywhere except a closed ticket.
Arpan Kundu on Al Fursan. Raneen on UX. Sahil Kumar, Mohammed Ehtisham, Nadeem Siddique in the engine pool. Manoj Dhiman on infrastructure.
Tahsin Ali facilitating the OC legacy team. Prateek Srivastava on finance and reconciliation. Rohit on chatbot and automatic supply switching. Dmitriy on fulfilment APIs and AWB. Marthino Yuda on notifications.
Six processes carry almost everything. Each has its own diagram below.
| Id | Process | What moves | Whose |
|---|---|---|---|
P-01 | Order in the Old World | Member buys, points burn at the client, MGC fulfils | Marketplace and Platform |
P-02 | Order in the New World | Same purchase through Core, OMS and the Fulfillment Service | E-Commerce Solution |
P-03 | Catalog and stock sync | Seller Portal to Core to Online Catalogue to MGC, plus the synchronous decrement | Both, this is the bridge |
P-04 | Seller on record | Who the seller really was, resolved after the order | Both |
P-05 | Points: burn, exchange, earn, payout | Every path money and points take | Platform |
P-06 | The Al Fursan migration | Canary cohorts, parity comparison, kill switch | All three teams |
The shop orchestrates. It holds neither the points nor the inventory.
Process P-01. Points live at the client, inventory and money live at MGC, and the shop orchestrates while holding neither.
Read step 3 against step 3 of P-01. That is the migration in one comparison.
Process P-02. Same purchase, new stack. Compare step 3 with P-01 step 3.
Three routes. Two run today, one is agreed and not built.
Process P-03. The live bridge between the two stacks. Scope is physical merchandise only. Gift cards, digital codes and vouchers are excluded.
The original plan was a direct bridge from the Seller Portal to legacy MGC. That was dropped in favour of syncing to the Online Catalogue instead, because OC already had an automated sync into MGC that had been running for months. The method changed at the same time, from pull-based polling to bi-directional webhook push.
Seller warehouse addresses live in the Identity Service. The Fulfillment Service mirrors them and registers the corresponding pickup locations with OTO.
Resolved after the order, not before it.
Process P-04. Seller resolution happens after the order, not before it. This applies only to Merit-seller orders, meaning catalogue-sourced ones.
Every path that money and points take. Three of these four have no New World counterpart.
Process P-05. Merit never holds the points. It reads them, burns them, converts them, and pays value back out.
Saudia only. Every other client stays on legacy.
Process P-06. A canary rollout, not a shadow run. Real members transact on the new system in growing cohorts, each compared against legacy before the next one opens.
Gift card fulfilment does not move at all. The legacy system becomes a supplier sitting behind Merit's own pipeline: storefront, then E-commerce Core, then order state management, then the Fulfillment Service, and only then does legacy issue the card.
No single person can answer "what does Al Fursan do today". The behaviour is split three ways: Aditya's code and routes, Akshay's platform services, and rules that exist only in the Ops team's heads. Those are the three discovery lenses.
Green works today. Amber is partial. Red does not exist. This is the register the migration is actually measured against.
| Capability | Old World, live today | New World | ||
|---|---|---|---|---|
| Shop and storefront | ||||
| Branded storefront per client | works today | Five bespoke builds: Saudia, SAIB, Kantar Verian, Mastercard, MCM | partial | Tenant provisioning for the Storefront Admin Portal, still to do. The single largest item in the migration |
| Content and CMS pages | works today | Content API | does not exist | basic CMS, to do |
| Product search | works today | tuned over years | partial | advanced search, in progress and untuned |
| Data-driven product ordering | works today | materialized view ranking | does not exist | no counterpart |
| Promotions engine | works today | done on legacy | does not exist | no counterpart |
| Catalog and supply | ||||
| Merchandise catalog, source of truth | works today | the legacy Merchandise Service | partial | catalog management, in progress |
| Product import split | works today | live on legacy | partial | in progress |
| Catalog selection and approval per client | works today | live on legacy | does not exist | no counterpart |
| Merit Online Catalogue | works today | the current Old World catalog system | partial | PIM replaces it. Sellers re-upload their catalogue rather than migrating product data |
| New variant on an existing product, synced | works today | OC does it internally | does not exist | agreed, not built. Waiting on the OC side to replicate it |
| Seller Portal API for suppliers | not applicable | suppliers are onboarded by Merit staff | does not exist | individual and bulk upload exist, an API does not. Blocks supplier migration |
| Orders and fulfilment | ||||
| Order placement and inventory | works today | MGC is the source of truth | works today | E-commerce Core plus OMS |
| Gift card fulfilment | works today | MGC mints or calls the supplier | works today | reclassified, not a gap: legacy becomes a supplier behind the Fulfillment Service |
| MGC lazy fulfilment | works today | live on legacy | partial | MGC legacy sync, in progress |
| Order item fulfilment cooling period | works today | live on legacy | does not exist | no counterpart |
| Bulk order placement via admin portal | works today | live on legacy | does not exist | how corporate bulk redemptions actually get placed |
| Admin order lookup for support | works today | Saudia admin dashboard | does not exist | not built. Third-party support cannot find an order |
| Location-aware stock, STC | does not exist | legacy was built for gift cards, it has no location awareness | works today | warehouse-location aware, matches STC city-level stock |
| Money | ||||
| Points burn against the client programme | works today | shop calls the client LMS | partial | the same client APIs still have to be wired per tenant |
| Points exchange | works today | six partner programmes live | does not exist | no counterpart. Point Exchange stays Old World; the New World calls it rather than rebuilding it |
| Payouts | works today | PayPal and Revolut live | does not exist | no counterpart. Payout Service stays Old World; the New World calls it rather than rebuilding it |
| Earn model, cashback in miles | works today | proven on legacy | does not exist | not built. Blocked on a Saudia Finance funding percentage, not on engineering |
| Client float management | works today | MGC, with an open negative-balance race | does not exist | no counterpart described |
| Reconciliation with SAB | does not exist | explicitly not implemented | does not exist | not scoped |
| API client onboarding | works today | clients place orders straight into MGC by API | does not exist | no path for them |
| Messaging and integration | ||||
| SMS and email | works today | live on legacy | partial | notifications, provider layer sits with Marthino |
| works today | runs through Saudia’s Accenture system | does not exist | must move to Merit. No team assigned | |
| Internal webhooks and sync | works today | live on legacy | works today | done. The one clean match in the whole register |
Ten capabilities are live on legacy and absent from the new stack. Two of the reds are not gaps at all: gift cards were reclassified, legacy becomes a supplier, and RewardsBy is out of scope. One row runs the other way: location-aware stock for STC exists only in the New World, because legacy was built for gift cards and has no location awareness.
Five choices come out of the register. Each is written as options with a recommendation, so approving one costs a word. None of them are decided.
Decision needed
The new stack needs generic tenant provisioning, and it is still to do.
Hand-provision Al Fursan for the canary rollout. Generic provisioning is the right product to build, but should not block the rollout.
Decider: Khawar, Brian
Decision needed
The mechanism is built and proven on legacy. The blocker on the new side is a funding percentage from Saudia Finance.
Build now, configure later. A pending commercial number should not hold engineering time.
Decider: Brian, Hamza Shahbaz
Decision needed
Both are done on legacy and absent from the new stack. Neither breaks an order.
A fast follow, unless Saudia treats either as launch-blocking. They move revenue, they do not affect correctness.
Decider: Brian, Aditya
Decision needed
Bulk and individual upload exist, a programmatic API does not, and its absence blocks supplier migration.
Before. Every supplier migrated by hand is a supplier that has to be migrated again.
Decider: Khawar
Decision needed
They run through Saudia’s Accenture system today and have to move to Merit. No team is assigned.
Give it an owner soon, whichever way it goes. Unowned, it becomes a rollout blocker instead of a scheduled task.
Decider: Akshay, Marthino
All recorded in the system's own documents. None of this is folklore.
Finance recorded a race condition that drives a client's prepaid balance below zero. No fix is recorded against it.
MGC is an enhancement on top of a system built for something else. Many tables are unused and no clean ERD exists. Never infer meaning from a table name.
Ranks of 5, 99 and 999 are conflated with "not pinned", so most of the Saudia catalog falls through to alphabetical order. A fix replacing them with NULL is a hard prerequisite.
MGC runs on both. Blue/green Aurora deployment, four to ten minutes of downtime. Whether ElastiCache carries queue state was still unconfirmed.
Ops copies product data into each client panel, updates merchandise order statuses by hand, and distributes gift cards by email and spreadsheet. If your change moves a manual step, tell Ops before you ship.
The Go marketplaces carry their own pkg/catalog, pkg/loyalty and identity.Service instead of calling Platform for all of it. A getEnvVariables helper is pasted into six packages.
Every supplier is wired separately. There is no adapter to reuse. Budget for it every single time.
CloudFront logs stopped reaching New Relic while New Relic kept returning 200. The Lambda applied Lambda-shaped filtering to CloudFront JSON and dropped every record. Check the destination, not the status code.
Ranked by how much you can trust it.
merit-incentives/marketplaces/*, merit-incentives/platform/*, merit-incentives/mgc/*. You will also find marketplaces/saleor/saleor-core. A 2023 ticket calls Saleor "the engine of our e-commerce workflows" for "the next generation of Merit Marketplace", and adds that it "is still experimental". Nothing in any roadmap, plan or sprint since then mentions it, and the Go marketplaces are what actually went to production. Treat it as an abandoned line until someone tells you otherwise, and ask before building on it.2199617558 and 2266365953. The only reliable current-state view of Platform Services.2133852161 and 2133262338. The best architecture writing on the Marketplace side.#temp-ecomm-core-x-online-catalogue-sync, #seller-portal-x-merchandise-service, #merit-mgc-1-0-tech, #urgent-tech-ops, #proj-oto-integration, #marketplace-support-requests.Take a recent Al Fursan gift card order and walk P-01 yourself, from the SSO redirect to the datalake row. Write down every point where you had to ask a human. That list is your onboarding gap.
Both Jira instances, Linear after cutover, Confluence space ME, the Slack channels above, the Merit Drive product folder. Access is the bottleneck.
saudia-marketplace. It is the reference for the whole family: Go, Gin, Postgres with GORM, goose migrations, Redis, River workers, Keycloak, New Relic. Focus on pkg/catalog, pkg/orders and the River workers.
The contrast is the migration. Every Old World behaviour with no home in the new model goes into the parity register in section 05.
| Ask | Of |
|---|---|
| Does ElastiCache carry queue state, or is it cache only? It changes how the upgrade is planned. | Akshay, Rohit |
| Are backend deploys still manual anywhere, or is GitLab CI/CD complete? | Manoj Dhiman |
| Has the NULL rank convention shipped? | Aditya, Arpan |
| Has the OC side agreed to replicate the variant-refresh mechanism, route C in P-03? | Akshay, Muneeb |
| Which Al Fursan rules are uncoded, and who holds them? | Muawiya Mawi, Raneem Ajana |
Everything you will hear in week one.