E-commerce & System Integrations

I’ve worked with several e-commerce platforms over the years, including PrestaShop and Magento. But my deepest experience has been with Shopware 6.

I like Shopware for a fairly simple reason: it is a genuinely capable engineering platform.

It’s Symfony-based, highly extensible, has a strong plugin ecosystem and gives developers a lot of freedom to adapt the platform to very different business requirements.

I’ve worked on around six Shopware-based projects, covering:

• Plugin development
• Custom entities
• Checkout
• Pricing
• Search
• Store API & Admin API
• Sales channels
• Platform customization

But over time, I learned that the Shopware part is often not the hardest part.

The shop is usually only one piece of the system.

In a serious e-commerce environment, the customer sees a webshop. Behind it, there might be:

And often the data flows back in the other direction as well.

I’ve worked with systems involving platforms such as Pimcore, Microsoft Dynamics 365 Business Central and other ERP/PIM systems, with data moving in both directions.

Product information might originate in a PIM. Stock might come from an ERP. Orders need to flow back into the ERP. Customer-specific prices may need to be calculated using information that doesn’t actually live in the shop.

The webshop becomes the place where all of these systems have to come together.

That’s where e-commerce architecture gets interesting.

One of the recurring architectural decisions was whether data should be imported and stored locally, or retrieved from another system in real time.

There isn’t one correct answer.

For relatively stable data such as products and stock, we generally preferred synchronization and local storage. For dynamic information such as customer-specific pricing, live calls were often necessary.

But live calls have a cost.

A customer shouldn’t have to wait for an ERP response just to see a product page.

So caching became an important part of the architecture. We used technologies such as Redis and OpenSearch, together with application-level and HTTP caching strategies, depending on the problem.

The goal wasn’t to eliminate live integrations. It was to make sure the customer experience didn’t depend on every backend system responding perfectly, every time.

Customer-specific pricing is a particularly good example. Imagine millions of possible price combinations across:

• Products
• Customers
• Customer groups
• Contracts
• Currencies
• Markets
• Pricing rules

At that point, calculating everything dynamically for every request simply doesn’t scale. But importing every possible combination isn’t necessarily practical either.

So the architecture becomes a balance between:

Sometimes the right answer is caching. Sometimes it’s precomputation. Sometimes it’s a live call. And sometimes it’s a combination of all three.

This is where e-commerce stops being primarily about building a webshop and starts looking much more like distributed systems engineering.

Shopware gives you a lot of abstraction. That’s useful — until the abstraction becomes the bottleneck.

I’ve encountered situations where the standard data access layer wasn’t performant enough for the workload. The answer wasn’t to abandon the platform. It was to understand what was actually happening underneath it.

That sometimes meant:

• Raw SQL for performance-critical queries
• Redis caching
• OpenSearch for search-heavy workloads
• Application-level caching
• HTTP caching
• Varnish
• Reducing unnecessary backend calls
• Changing when and where data was calculated

The important part was knowing when to stop relying on the abstraction and go one level deeper.

That’s one of the reasons I still value being hands-on as an architect. You can’t always solve a performance problem from an architecture diagram.

Sometimes you need to look at the query.

I’ve also seen the other side of this problem.

In one environment, the ERP was effectively the leading system for important parts of the business. When the ERP became unavailable, parts of the customer-facing functionality had to be disabled. Customers would see messages explaining that certain operations — such as placing orders — were temporarily unavailable.

Technically, the webshop was running. The servers were healthy. The application was healthy. But one of its dependencies wasn’t.

That experience reinforced something important:

System reliability is not just about whether your application is running. It’s about what happens when the systems around it aren’t.

Good integration architecture therefore needs to consider:

• Timeouts
• Retries
• Caching
• Fallbacks
• Failure modes
• Stale data strategies
• Graceful degradation

The happy path is easy. The interesting architecture starts when something goes wrong.

One of Shopware’s strengths is its extensibility. There is a large ecosystem of plugins, which can dramatically reduce the amount of custom development required.

But plugins are still software.

I’ve encountered poorly written plugins, bugs, performance problems and situations where getting answers or fixes from the original developer was difficult. A plugin can look like a shortcut during implementation and become technical debt later.

That’s why I don’t evaluate plugins only by what they add. I also look at:

• Code quality
• Architecture
• Performance
• Update strategy
• Compatibility
• Vendor responsiveness
• How deeply the plugin changes the platform

An extension is part of your architecture once you put it into production.

After working across multiple commerce projects, I’ve become less interested in the question:

“How do we customize the shop?”

and more interested in:

“Where should this responsibility actually live?”

• Should the PIM own the product?
• Should the ERP own the stock?
• Should pricing be calculated centrally or locally?
• Should the shop make a live call?
• Can the data be cached?
• What happens when the ERP is unavailable?
• What is the acceptable amount of stale data?
• Where should business logic live?

These decisions have much more impact on the resulting system than the choice of a particular plugin or framework component.

The architecture has to account for the whole system, not just the storefront.

I’ve enjoyed working with Shopware because it sits at an interesting intersection.

It’s a powerful platform, but it doesn’t try to solve every problem for you. The real engineering work starts when the shop becomes part of a larger ecosystem.

After working across multiple complex commerce systems, I’ve learned to see the storefront differently. It’s not the product. It’s the interface to the product.

The real product is the system behind it — the data, integrations, business rules, performance characteristics and failure modes that make the commerce experience possible.

Shopware 6 · Symfony · API · ERP/PIM · Redis · OpenSearch · Varnish