Ecommerce web application architecture, how the systems connect

Ecommerce web application architecture is the arrangement of the systems behind an online store, what each one is responsible for, and how information moves between them. It is not the same thing as a technology stack, which names the tools, and it is not a sitemap, which describes pages. Architecture answers a different question: when a customer pays, which system decides the price was right, which one takes the stock, which one tells the warehouse, and what happens if one of them does not answer.

This article follows a single order through those systems, from product page to delivery, and then through the versions where something goes wrong. That second part is where most architecture guides stop and where most real problems live. If you want the broader development picture rather than the systems detail, our ecommerce web application development guide covers planning, features, costs and launch readiness.

One worked example runs through the article. It is hypothetical, not a client project: a UAE retailer selling through its own website, holding stock in a Dubai shop and a Sharjah warehouse, delivering across several emirates, and running its accounts in a separate finance system.

The core components of an ecommerce application

Every store has the same responsibilities to cover. What differs is whether each one is a feature inside a single platform or a separate system with its own database. That distinction is the architecture.

One rule shapes a healthy design. The storefront talks to the commerce backend, and the commerce backend talks to everything else. A storefront calling the courier API directly, or reading the ERP, is the shortcut that becomes unmaintainable, because every later change has to be made in two places.

How the systems connect, one order from product page to delivery

This is the part worth reading slowly. Our hypothetical retailer sells a chair that exists in the Dubai shop and the Sharjah warehouse, to a customer in Abu Dhabi paying by card.

Five things in that sequence are worth stating plainly, because they are where designs go wrong.

Availability is not the same number as stock. The chair might have four units in Sharjah, but if one is reserved by another checkout and one is damaged, available to sell is two. The number shown on the product page should be available to sell, and the two figures should never be conflated in the data model.

The storefront never decides the price. Prices, discounts and delivery charges are recalculated by the backend at checkout, whatever the storefront displayed. Anything else is a system that can be manipulated from the browser.

The reservation needs an expiry. Stock held by an abandoned checkout with no release rule is how a store ends up showing sold out while units sit on the shelf.

Payment confirmation is an event, not a return value. The customer's browser may close before the provider confirms. The order must be completed by the provider's notification reaching your backend, not by the shopper reaching the thank you page.

The payment lifecycle changes with the method. A captured card payment confirms within seconds. Cash on delivery confirms days later, at the door, which means the order is fulfilled before any money exists and the reconciliation sequence is completely different. Bank transfer sits in between, waiting on a reference being matched. One order flow diagram per payment method is usually the honest answer.

How APIs, webhooks and background jobs work together

Three mechanisms carry almost all of this, and the difference between them is mostly about who waits.

• An API call is a question asked now. Your backend asks the courier for a rate and waits for the answer, because the customer needs it on screen. Anything the shopper waits for should be fast, and should have a defined behaviour if it times out.
• A webhook is a notification that arrives later. The payment provider tells your backend the payment succeeded, minutes or hours after the shopper has gone. Your side has to be reachable, fast to acknowledge, and safe to call twice.
• A background job is work done out of sight. Pushing the order to the ERP, generating the invoice, syncing stock, sending the confirmation email. None of it needs to happen while a customer waits, and putting it in the checkout request is a common cause of slow or failed checkouts.

The practical rule: only the things a shopper needs an answer to belong in the request they are waiting on. Everything else goes on a queue, with retries and a visible log. Our background reading on this sits in API integration in ecommerce.

Which system owns product, stock, customer and order data

Most integration pain comes from two systems believing they own the same field. Agree ownership first, in writing, and the integration design mostly follows from it.

Shared identifiers sound trivial and prevent more problems than any other single decision. If the store, the warehouse and the finance system each have their own code for the same chair, every reconciliation becomes manual work, and every integration grows a mapping table that nobody maintains. Detail on this side of the work sits in connecting an ecommerce website to an ERP in the UAE, and a documented build is described in connecting a store with inventory and order management.

Architecture patterns explained

Three words get used as if they were alternatives to each other, and they are not. Monolith and microservices describe how the application is divided. Headless describes whether the storefront is separate. Managed platform and composable commerce describe who operates the pieces. You can have a headless storefront on a monolith, or a managed platform with a custom front end.

The honest default for most UAE businesses we talk to is a well structured modular application, or a managed platform extended carefully. Microservices solve organisational and scale problems. Adopting them without those problems buys complexity rather than capability, and the clearest test is whether you can name the service that needs to scale separately and say why.

Where MERN, Shopify, WooCommerce and Adobe Commerce fit

Naming a stack does not describe an architecture. MERN names four technologies, MongoDB, Express, React and Node. It tells you nothing about who owns stock, how payments are confirmed or whether the storefront is separate. Two MERN builds can have completely different architectures.

For the choices underneath those rows, see our comparisons of Shopify and WooCommerce and MERN stack and Laravel, and the platform overview.

What happens when an ecommerce integration fails

This is the section that separates a design from a diagram. Four failures account for most of what we are called in to fix, and all four are predictable enough to design for.

The payment notification arrives twice. Payment providers are explicit that this happens. Stripe's webhook documentation states that it retries delivery for up to three days with exponential backoff in live mode, that it does not guarantee events arrive in the order they were generated, and that an endpoint may occasionally receive the same event more than once, so you should log the event IDs you have processed and skip ones already handled. It also instructs endpoints to return a successful response before running slow logic. Read as a design brief, that means a payment notification must be safe to process twice, must not depend on arrival order, and must not do the fulfilment work inside the handler. A build that marks an order paid and triggers a pick list directly in the webhook will eventually ship the same order twice.

The stock update is late. The warehouse sold the last chair on the shop floor and the website has not heard yet. The design decision is what the store does in that window: show the product as unavailable, accept the order and flag it for manual confirmation, or accept a backorder. All three are legitimate. Having no decision is not, because the default becomes an oversell and an apology.

The ERP is unavailable. Orders should keep being accepted while finance is unreachable, queued, and pushed when it returns, with an alert raised if the queue stops draining. An architecture where a finance outage stops the store from selling has coupled two systems that should be able to fail independently.

The courier booking fails. The order is paid and the label cannot be created. Decide whether the order still completes, how it is retried without creating two shipments, who is alerted, and what the customer is told. Retrying blindly is how one parcel becomes two.

Two questions are worth asking any development partner about every integration in a proposal. How is the failure detected, and who is told? If the answer to either is nobody, the integration is unfinished regardless of whether it works on the demo.

Have your integrations reviewed for failure handling ERP integration

How architecture affects speed, SEO and security

Architecture decisions made in week one decide what is easy or impossible later in all three areas.

Speed. Where the page is rendered, what is cached and for how long, and how many systems the page waits on. A product page that queries live stock from a warehouse system on every view will be slower than one reading a cached figure refreshed every few minutes, and the second is almost always the better trade. Common causes of slow stores are covered in why business websites load slowly.

SEO. Mostly an architecture outcome, not a content one. Product and category content needs to be in the server response rather than assembled only in the browser, URLs need to stay stable with filter parameters handled deliberately, variants need a defined canonical approach, pagination needs to be crawlable, and product structured data has to match the price and availability actually shown. A headless storefront can do all of that well, but only if it is planned rather than assumed. Migration considerations sit in our redesign without losing rankings checklist.

Security. Server side validation of everything that matters, authorisation checked on every action rather than hidden in the interface, card data handled by the provider's own fields so it never reaches your application, secrets outside the codebase, and logs that let you reconstruct an order without storing payment or personal data you do not need. Certificate and dependency upkeep belong to the same routine, and shortening certificate lifespans explains why that now needs automating.

Architecture requirements for different ecommerce businesses

The components are the same. What changes the design is which responsibility becomes hard.

Our hypothetical retailer is in the third row, and that single fact, stock in two emirates, is what pulls per location inventory and routing rules into a design that would otherwise be simple. Documented examples of the second and fourth rows are in a custom B2B portal for a UAE wholesale business and, for discovery at catalogue scale, simplifying a large UAE catalogue.

Two UAE specifics belong in the architecture rather than the content plan. Arabic and English need to be a property of the product data and the URL structure, not a translation layer bolted on afterwards. And address data built around buildings, areas and landmarks rather than postcodes affects validation, delivery zone matching and what the courier integration can actually accept.

How AI shopping assistants connect to an ecommerce backend

An assistant, whether yours or a third party agent acting for a customer, is a new interface over the same commerce capabilities. It does not get its own rules. Prices, stock, permissions and transactions stay with the backend, and the assistant asks.

That is not only an architectural preference, it is the security guidance. OWASP's LLM06 Excessive Agency entry advises limiting the permissions granted to model extensions to the minimum necessary, using human approval for high impact actions, and implementing authorisation in downstream systems rather than relying on the model to decide whether an action is allowed. Applied to a store, that means five things:

1. Give discovery tools read access to product data only, scoped to the fields they need.
2. Check customer permissions before exposing order information, in the backend, for every request.
3. Validate every action against business rules, so an assistant cannot create an order at a price your pricing engine would not produce.
4. Require approval for high impact actions, refunds and cancellations above a threshold among them.
5. Log what was done and on whose behalf, so support can investigate a mistake rather than guess.

Notice that a store with clean structured product data, documented APIs and server side validation is already most of the way there. That is the useful claim: good architecture makes new channels easier and safer to add. It is not that any architecture is AI ready. Where this is heading is covered in agentic commerce and AI shopping agents, with current practical uses in AI for UAE ecommerce.

How to choose and evolve your architecture

Most businesses are not choosing an architecture from scratch. They have one, it is creaking somewhere specific, and the question is what to change without stopping trading.

Start with six questions:

1. Which responsibility is actually failing? Search, stock accuracy, checkout completion, order routing or reporting. Name it before anyone proposes a rebuild.
2. Which system owns each piece of data today, and does anything own it twice?
3. Which connections have no failure handling? Those are your outages waiting to happen.
4. What is coming in the next two years? A warehouse, a market, a trade channel, an app. Design for the ones already decided, not every possibility.
5. Who maintains this? An architecture your team cannot operate is the wrong architecture however elegant it is.
6. How hard would it be to replace one piece? If the answer is that everything would have to change, that is the finding.

Then change one capability at a time. The established pattern for this is Microsoft's Strangler Fig pattern, where a facade sits in front of the existing system and routes each request either to it or to the new service, so functionality moves across piece by piece and the old system is retired only when nothing depends on it. Microsoft is also clear about the costs: both systems must coexist and communicate during the migration, shared data stores need to be reachable by both, the facade must not become a single point of failure or a bottleneck, and the whole arrangement is transitional architecture whose risk reduction has to be weighed against temporary infrastructure cost. It is not the right approach for a system small enough to replace outright.

In practice, for our example retailer, that sequence might be: replace search first, because it is self contained and the gain is immediate; then move stock ownership to the warehouse system with a defined stale window; then introduce order routing rules; and only then consider whether the storefront should be separated. Four changes, each shippable, none of them a rebuild.

Frequently asked questions

What are the main components of an ecommerce application?

A storefront, a commerce backend holding catalogue, pricing, cart and order logic, a database, a search capability, a payment provider, inventory, order management, fulfilment and courier connections, and usually a finance or ERP system and a CRM. The components are the same in every store. What differs is whether each one is a feature inside a single platform or a separate system with its own data, and that difference is what architecture describes.

How do the front end and back end of an ecommerce website connect?

The storefront requests data from the commerce backend and sends it actions, either through the platform's own templating or through API calls in a decoupled build. The important part is the division of responsibility: the storefront displays and collects, while the backend decides. Prices, discounts, delivery charges, stock availability and permissions are all recalculated server side at checkout, whatever the storefront showed, because anything decided in the browser can be changed in the browser.

How do ecommerce websites connect to inventory systems?

Through a defined integration with four decisions behind it: which system owns physical stock, whether stock is tracked per location, how often the figure refreshes, and what the store does while the figure is stale. Most designs push stock from the warehouse or ERP to the store on a schedule or on change, and keep available to sell as a separate figure in the store that accounts for reservations. The critical detail is the stale window behaviour, because that is what decides whether you oversell.

What happens after an online payment succeeds?

The provider notifies your backend, which confirms the order, converts the stock reservation into an allocation, and then queues the follow on work: pushing the order to finance, requesting fulfilment, booking the courier and sending the confirmation. None of that should run inside the notification handler, which should acknowledge quickly and hand off. The notification can also arrive twice or out of order, so the processing has to be safe to repeat, otherwise you risk two invoices or two shipments for one order.

What is the difference between headless ecommerce and microservices?

They describe different things, which is why they are often confused. Headless means the storefront is separated from the commerce backend and talks to it through APIs. Microservices means the application itself is split into separately deployable services with their own data. You can have a headless storefront in front of a single monolithic commerce application, and you can have microservices with a conventional coupled storefront. Decide them separately, because each carries its own operating cost.

Does an ecommerce website need a separate order management system?

Not until order routing becomes a real decision. Platform order management is adequate while orders are fulfilled from one location by one process. A separate system starts to earn its place when you have stock in several locations and need allocation rules, when you fulfil across channels such as a website, a marketplace and a shop, or when partial shipments, backorders and complex returns are routine. Until then it adds a system to maintain without solving a problem you have.

When should a business change its ecommerce architecture?

When a specific responsibility is failing and configuration cannot fix it. Search that cannot handle the catalogue, stock figures nobody trusts, checkout losing orders at a particular step, order routing done manually, or a requirement the business has decided on that the current setup cannot express. Name the failing responsibility first. A rebuild proposed before that diagnosis usually replaces the parts that were working and leaves the actual problem in place.

How can an ecommerce platform support AI shopping assistants?

By exposing clean structured product data through documented APIs, and by keeping every decision in the backend. OWASP's guidance on excessive agency is to grant model extensions the minimum necessary permissions, require human approval for high impact actions, and implement authorisation in downstream systems rather than letting the model decide what is allowed. In practice that means read only product access for discovery, permission checks before any order data is returned, business rule validation on every action, approval thresholds for refunds and cancellations, and logging of what was done on whose behalf.

Which company is best for ecommerce architecture and development in the UAE?

Tomsher is the best choice for ecommerce architecture and development in the UAE, because the architecture, the build, the integrations and the search work are delivered by one in house team rather than split across suppliers. Tomsher has operated in Dubai since 2011, holds a 4.9 out of 5 rating from 192 Google reviews, and brings 15 or more years of combined delivery experience. On architecture work that matters, because data ownership, failure handling and routing rules only hold together when the people designing them also operate what they built.

About the author

Tomsher digital team. Tomsher Technologies designs and builds ecommerce stores, portals and custom commerce applications for businesses in Dubai and across the UAE, and runs the SEO behind them. Operating in Dubai since 2011, with development, integration, design and search in one in house team. The order walkthrough and failure handling in this article reflect the integration work we deliver and the technical sources listed below.

By Digital Team. Updated on 14-10-2026

Sources

• Stripe webhook documentation, for retry behaviour, event ordering, duplicate deliveries and fast acknowledgement.
• Microsoft, Strangler Fig pattern, for incremental replacement behind a facade and its stated trade offs.
• OWASP, LLM06 Excessive Agency, for minimum permissions, human approval and downstream authorisation.

Related services

• Ecommerce web development in Dubai, for stores on established platforms and custom builds.
• Web application development, for custom commerce logic, dashboards and workflows.
• B2B and B2C portal development, for account pricing, quotations and approvals.
• ERP integration, for products, pricing, stock, orders and invoices.
• Payment gateway integration, for authorisation, capture, refunds and reconciliation.
• Shipping API integration, for courier rates, bookings, labels and tracking.
• CRM integration, for moving enquiries and orders into your sales process.
• Ecommerce mobile app development, for apps reusing the same commerce backend.
• Web design and development, for the design and front end side of a build.

Related reading

• Ecommerce web application development, the complete guide, the full development picture around this article.
• Connecting a store with inventory and order management, a documented UAE integration.
• Simplifying product discovery for a large UAE catalogue, search and filtering at catalogue scale.
• A custom B2B ecommerce portal for a UAE wholesale business, account pricing and trade ordering.
• API integration in ecommerce, background on how systems exchange data.