Bru Textiles: The Strangler Fig Pattern in Practice

Introduction

Bru Textiles is a family business based in Kontich, Belgium, supplying interior furnishing fabrics for upholstery, curtains and drapery under brands including FibreGuard and Fabric Library. Bru ships millions of meters of fabric a year from stock to more than 100 countries, serving fabric brands, furniture manufacturers, and the hospitality and healthcare sectors.

Partner companies around the world run on the same core systems, so every system Bru builds has to work for the whole group. Two of those systems are built and run by a small team of fewer than ten Java engineers: WHS, the warehouse system that tracks every roll of fabric from receiving to shipping, and the Twinbru Engine, which turns physical fabrics into digital twins that designers and brands can use without a physical sample.

Both run on the Axoniq Platform, and both grew out of a decision Bru’s team made early on: keep the full history of what happened as part of the system itself.

"We chose Axon to break our warehouse system into truly independent services and to keep the full history of every roll as part of the system itself. Today one installation carries our fabric rolls through warehouses in 13 countries, event sourcing gives us the full history of each roll by design, and Axoniq's engineers have been knowledgeable partners who engage with our real problems."

Koen Verwimp, Software Engineering Lead, Bru Textiles

The Challenge: A Monolith Every Warehouse Depended On

Bru's warehouse system was first written in the early 2000s, and the warehouses depend on it every day. Bru sells fabric by the meter, so almost every order relies on knowing which roll is where, how much is on it, and which dye batch it came from. Bru’s team knew that replacing it in one big-bang rewrite was not an option.

Every roll in Bru’s warehouses gets cut, split, moved and corrected, and as the group grew, the platform tracking all of it was getting harder to change. The team started with four problems:

1. Transaction scripts across several systems

One action ran as a single procedure that updated stock, adjusted the delivery and notified the ERP system in one large transaction. If one part failed, everything failed.

2. Services tied to each other's databases

Every part of the system knew too much about the others, so a new screen or report meant a new dependency.

3. No easy answer to "what happened to this roll?"

Every cut, split, move and correction changes the remaining meters. Answering a question about a quantity, a quality or a dye batch meant digging through logs and audit tables.

4. A growing group

Partner companies were moving onto Bru's systems, and every new warehouse had to fit the same platform.

The Solution: Untangling the Monolith, One Bounded Context at a Time

Rather than gamble on a rewrite, Bru took the patient route. The team introduced Axoniq Framework inside the existing Java EE application for one domain, supplier management. Within weeks, receiving became its own service, followed by master data and the ERP integration, each connected through events. Bru has been untangling the monolith that way ever since, one bounded context at a time, while the warehouses keep shipping every day.

Each step added to the same event-sourced core instead of replacing it: the events written in 2017 are the ones the Warehouse Assistant reads today.

Events instead of transaction scripts: With Command-Query Responsibility Segregation (CQRS) and event sourcing, a service records what happened as an event and other services react to it. Each step is consistent on its own, and a failure in one service no longer blocks or rolls back the others.

Projections instead of shared databases: Each service builds its own read model from the events it needs, so it never queries another service's database. A new screen or report is a new projection built from history.

The history is the system: Every operation on a roll is recorded as an event with who, when, where and why, not written to an audit table after the fact. That history lets Bru answer who cut a roll, when, at which table, and why it's 3 cm short, years after the fact.

One installation, a context per warehouse: Today, WHS has run multi-tenant, with one Axon Server context per warehouse. A new warehouse is a new context and some configuration, not a new installation.

The same foundation, a second platform: When Bru started the Twinbru Engine, choosing Axon again was straightforward. Its domain is a chain of business facts (a fabric is scanned, a material is created, a render is requested, approved and published), and the work is long-running: a render can take minutes on cloud compute. The team reused the patterns and a shared Axon library it had built for WHS.

Axon decides, AWS computes: On the Twinbru Engine, Axon owns the business domain and its history, while AWS Step Functions, AWS Batch and AWS Lambda handle rendering and the API. When a render job finishes, a callback brings the result back into the Axon domain as an event. Both platforms run on AWS; WHS moved there from Bru's own data center in 2024.

Years of History, Ready for Questions Nobody Asked Yet 

Bru originally stored its warehouse events for operational reasons, and that early decision now pays off in ways nobody planned for. Today, every event from every warehouse streams into a data warehouse, and Bru's Warehouse Assistant answers plain-language questions over that full history, such as what was cut for a given customer last week. Because every transaction was kept, nothing that happened in the warehouse is outside the assistant's view.

Technical Impact

• No rewrite of the event-sourced core in ten years. Bru upgraded from Axon 3.0 in 2016 to 4.13 today and changed event store technology twice, and its events from 2017 are still readable, using upcasters where event shapes changed.

• One installation, 14 warehouses in 13 countries. WHS runs warehouses across Europe, Africa, the Middle East, Asia and Oceania, each with its own event store. The newest, in the UAE, went live this year.

• More than 400 million events across both platforms. That's about 326 million in WHS and about 105 million in the Twinbru Engine. Bru's largest warehouse alone holds about 138 million events.

• Render at scale. The Twinbru Engine can run 2,000 renders simultaneously and has produced more than 3 million renders from close to 25,000 scanned fabrics.

• Replays, not migrations. When a search model or report changes, the team rebuilds it by replaying events. Moving WHS to AWS was an infrastructure exercise, not a data migration, because the event store is the system of record.

• 99.5% uptime and about 40 platform releases a year, shipped in two-week sprints by a team of fewer than ten engineers.

Business Impact

• The group grows on one platform. Partner companies' warehouses move onto WHS as they join the group, including Home Fabrics, Sample King, Acacia, James Dunlop and Mercis.

• A stock promise customers can rely on. WHS picks the right roll from the right dye batch, keeps stock correct down to the individual roll, and gives customer service an accurate view of what's available and where every delivery is.

• Digital fabrics instead of physical samples. Designers, furniture makers and fabric brands visualise Bru fabrics in 3D long before anything is produced. Other fabric companies use the Twinbru Engine to digitize their own collections, each in its own isolated space.

• Imagery without new photo shoots. Bru's product and marketing teams produce images at scale through a self-service platform, reusing existing assets.

The History of Every Roll, by Design 

When a customer asks about a length, a quality or a dye batch, Bru doesn't reconstruct the answer from logs. Every cut, split and move is an event, so Bru can trace any roll back through every operation to the roll it came from. In its largest warehouse, that history goes back nearly a decade. 

The Role of Axoniq

When Bru’s engineers hit a problem, Axoniq’s support engineers and developers respond quickly and work on the issue itself rather than pointing them to the documentation. Axoniq’s robust documentation and training material serve as part of Bru’s onboarding process for new engineers. Bru also uses Axoniq Platform for visibility into event processors and dead letters.

Looking Ahead

Bru is preparing the move to Axon Framework 5, including its built-in multi-tenancy, while more group warehouses and fabric companies join its platforms.

After nearly ten years of running event sourcing in production, Bru’s advice for teams considering it for a system they’ll still run a decade from now is simple: Design events as if they're permanent, because they are. Name them after business facts, keep them small and explicit, and version them from day one. And start with one bounded context next to the existing system, rather than a big-bang rewrite.

Untangling your own monolith? Read how teams strangle a monolith with Axon Server, see what's new in Axoniq Framework, or talk to a solution architect about starting with one bounded context.