# E-commerce & System Integrations

> Case study: Shopware 6 projects where the real work was behind the storefront — bidirectional ERP and PIM integrations, customer-specific pricing and caching.

- Context: ~6 Shopware 6 projects
- Integrations: Pimcore, Business Central, ERP/PIM
- Focus: Pricing, integrations, performance
- Stack: Shopware 6, Symfony, Redis, OpenSearch
- URL: https://ferencfarkas.dev/work/shopware

## 01 — Context

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.**

## 02 — The Storefront Is the Easy Part

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

PIM → ERP → warehouse → pricing → inventory → Shopware → customer

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.

## 03 — Import What You Can. Calculate What You Must.

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.

## 04 — When Pricing Becomes a Distributed Systems Problem

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:

freshness · correctness · performance · cost

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.

## 05 — Performance Means Understanding the Platform

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.

## 06 — Your Slowest Backend Is Your Customer Experience

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.

## 07 — The Plugin Ecosystem Cuts Both Ways

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.**

## 08 — Integration Is Where the Architecture Lives

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.

### By the numbers

- **~6** — Shopware 6 projects
- **Millions** — Of pricing combinations handled
- **ERP + PIM** — Bidirectional integrations
- **Redis · OpenSearch · Varnish** — Performance & caching

## 09 — What I've Learned

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

- **A webshop is rarely standalone** — The customer sees one website. Behind it can be a network of systems, each with its own data model, availability, performance characteristics and failure modes.
- **Integration boundaries matter most** — Shopware, Symfony, an ERP and a PIM are just technologies. The difficult decisions happen at the boundaries between them — not at the boundaries between frameworks.
- **Cache strategically, not blindly** — Caching isn't simply a performance switch. Every cached value introduces questions about freshness, invalidation and correctness. In commerce, showing the wrong price can be considerably worse than showing a slow page.
- **Know your abstractions** — High-level APIs and frameworks make development faster. But when performance or correctness becomes critical, you need to understand what is happening underneath them. Sometimes the answer is a lower-level query, a cache, or changing the architecture entirely.

> The shop is only the storefront. The real system is everything behind it.

## 10 — Looking Back

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