In this episode, Sezin Cagil, Head of Unified Commerce Technology at Dr. Martens and MACH Alliance ambassador, shares hard-won insights on implementing and scaling MACH architecture in real-world environments. She explores how to approach modular migrations, manage complex vendor ecosystems, and prepare systems for high-traffic events. Beyond the tech, Sezin highlights the importance of team readiness, operational maturity, and aligning architecture with business needs. A must-listen for anyone navigating composable commerce or modern retail infrastructure.
Sezin Cagil is Head of Unified Commerce Technology at Dr. Martens, leading the teams through digital transformation and supporting omnichannel strategy. With expertise in agile delivery, composable architecture, and MACH principles, she drives seamless customer experiences across digital and retail channels. Previously, she led digital delivery at Selfridges and Costa Coffee, scaling international eCommerce platforms. As a MACH Alliance Ambassador, Sezin advocates for modern, modular technologies and contributes to industry thought leadership.
Episode transcript:
Jose
Hello and welcome to the Smooth Scaling Podcast, where we're speaking with industry experts to uncover how to design, build, and run scalable and resilient systems. I'm your host, Jose Quaresma, and today we had a great conversation with Sezin Cagil, Head of Unified Commerce Technology at Dr. Martens and an ambassador to the MACH Alliance.
MACH—written M-A-C-H—stands for Microservices, API-first, Cloud Native, and Headless. It enables you to easily compose a stack to fit your needs.
We discussed the alignment between business and technology strategies that produce great results, the benefits of a MACH approach, but also the challenges of orchestrating such an architecture with different vendors. And we also talked about the impact of traffic peaks. Enjoy.
Hi Sezin, welcome to the podcast.
Sezin
Hello, thanks for having me.
Jose
We're really happy to have you here. We’ll be talking about MACH, the MACH architecture, and the MACH Alliance. So, I'd love to start by asking: can you define MACH for us, and maybe also explain the main difference between that and a composable architecture?
Sezin
MACH is just an abbreviation that comes out of microservices-based, API-first, cloud-native, and headless. Those technologies have been around for a while. The MACH Alliance didn't create these technologies, they just came together to be outspoken about them, to spread the technology.
They actually make our lives better—at least as technologists—and for the consumer as well, since they get a better experience as a result. So that's mainly what the Alliance is doing: trying to spread the technology and create a community around it so these companies can work together. It becomes easier for enterprises to know who to talk to, where to go.
The thought leadership, I guess, is the most important piece—spreading the word, spreading the technology.
Jose
The other part I'm also interested in is: what about yourself? Can you tell us a little bit about your career and how you ended up interested in MACH?
Sezin
It was all coincidental. All coincidental, to be honest. I was working at Costa Coffee, leading the UK team and using the tech stack of MACH. We started to use Contentful, and as part of that, worked with an incredible senior engineer at the time, Jay Hoston, who put together a toolkit to build a website using Contentful and Netlify.
We could then spin up websites in fifteen minutes. We got so excited about this because we were asked to build global websites for different regions and markets. We started to promote it internally. Contentful got super excited. We went to their town hall, and then the first MACH conference was happening that year or the year after.
They invited us to talk about it, and I went with Gordon—Gordon Lucas, who was my manager at the time—to explain what we had done. That’s how I got involved with the MACH Alliance, completely coincidentally. I didn’t know them until Contentful introduced us.
Jose
So from your career, how would you say e-commerce has evolved? I mean, do you have some things you can share with us from an architecture trends perspective?
Sezin
Yeah, yeah, absolutely. When I first started to get involved in retail—because I worked in FinTech for a while and then moved to retail—there were lots of monoliths.
I found myself in a position to move out of one monolith after another, and I keep doing it. I’ve been doing it for the last quite a few—eight years or so now. One of the main moves was that monoliths became really expensive to run, to operate, to build over, to build features, functionalities, and experiences for consumers who were demanding more interactive, more experiential websites—or in general, digital experiences.
That, I think, was the main thing that shifted the enterprise from monolith to MACH architecture, where we could acquire smaller vendors—or you can buy it as a package as well—but still they are composable, so you can remove and add things as your business needs.
To me, almost all the retailers in, let's say, fashion or groceries, they would all need similar tech. But it all depends on the scale of the operation—how different it needs to be from that tech. The bigger you get, the more technology you will need; you will need to build the technology yourself.
But the smaller your operation is, you can operate with off-the-shelf technologies like Shopify, right? That’s why it became so popular—because it provides all the connectivity, it provides all the technology.
Jose
How do you see that variation in terms of—how does that correlate with maturity? So, I mean, do you look at MACH—at everyone out there using MACH architecture—as being on a spectrum of maturity? Or how do you think about that?
Sezin
I guess what makes MACH architecture mature is the ability of the organization to operate it, and also when they started the transformation. If they started the transformation ten years ago, they would have a mature architecture.
Now, they might actually need to change again, as technology evolves, digital solutions change, and consumer demands shift.
But at least they’ll have the know-how—how to operate, how to build on top of it, what to buy, what to get off the shelf, what to customize. I think that level of knowledge within the technology department is what I would call maturity.
MACH maturity depends on that know-how in the business. If the business doesn’t know how to operate that architecture, you can’t really have it. And that is probably one of the things to be careful about when working with composable.
If you go too composable for your scale, you can’t operate it. You’ll need bigger teams, and you’ll need more technical domain knowledge within the organization.
Jose
Okay, so some of that—as I hear you saying (please help me here because I could be misinterpreting a little bit)—is like, part of it is also maybe: the smaller you are, the less need you have for composability. Or to put it the other way, the bigger you get, the more it comes with a stronger need to be more composable, and also a stronger ability to do so.
Sezin
Sort of. I think you can still use MACH architecture or MACH technologies, but whether you use one single vendor or multiple vendors to build a layered architecture is a different question.
Even if you use one single vendor that says they're composable, that uses MACH architecture, you’re still MACH. That doesn’t change the nature of it.
Jose
Can you talk me through one example? Is Shopify one such example that you’ve mentioned?
Sezin
Yeah, yeah, absolutely.
Although I don’t think they’re actually part of the Alliance, when I look at it from afar—and I’m not here to promote anybody, I’m just looking at it as a technologist—when I look at it from afar, there are all these layers that they provide.
And whether you use that layer or not is your decision. It’s based on your business strategy, your business operation, the tech resources available, your expertise.
But they provide everything you need to be able to operate an e-commerce business. And the bigger your operation, the more complex you are, the more global you are—based on the regions that you support—the more separate layers you would need, the more extensive capabilities you would need.
Otherwise, for instance, it has a PIM already that comes with it. You can just use that. But if you have a bigger, more complex product range and operation, you would need a separate PIM that can support that complexity. I guess complexity is the right word there.
Jose
I don't know if it's degrees of freedom or kind of specific needs—that as you get bigger, maybe won’t be addressed by a basic MACH architecture setup.
So you'd need more freedom, more capability—for example, on the PIM side—to do some more customized configurations.
Sezin
Yeah you might need to bring in more customized or specialized solutions.
It also depends—you might have a simple-looking complex business. From the outside it might look simple, but your operations could be very complex, or you might be spread across the world for whatever reason. All those things impact the architectural decision.
Technology is not separate from the business. It supports the business. It will follow the business.
Jose
Ideally, yes.
Sezin
I guess that’s another problem with monoliths, right? They can’t move as fast as the business changes.
You then need to move to a MACH architecture, where you can start to have that modularity. You can then start to make decisions.
Jose
Yeah, I see that. And can you give us an example of some of the more... maybe the more complex MACH architecture setups? I don’t know if you can give a specific one or just talk a bit generally.
Sezin
I guess we can talk at a high level, yeah, definitely. Let's start from where the consumer starts—the front end.
You always want that front-end layer to be unique to you. It’s brand-driven; it depends on the tone of voice you're using. So that layer is generally done completely separately. But you need content management systems—CMS—to power that layer so that your business teams, content teams, can go and update content regularly, instantaneously, without going through the development team.
You then have a product range that comes through an e-commerce engine. That engine would probably connect—depending on the scale—to a PIM, a product information management layer, where you have all the attributes and details.
That would then connect to an order management system, which of course processes the orders and delivers them.
That in turn talks to a warehouse management system, because that’s where the products are packed and shipped.
You might also need a customer data platform, because there are lots of consumers interacting with your systems. You want to retain that data to provide personalized experiences—especially in today’s world. And that data layer will become really valuable down the line as you start using AI more.
And of course, these are the layers that the business and customers interact with. You also have reporting, analytics, alerting, monitoring—the list is endless. There are quite a few different layers to manage in order to operate an e-commerce business.
Jose
Yeah. And I could imagine—I'm drawing a parallel here with microservices—I could imagine that once you have all those different composable components in the architecture, it gets quite complex to orchestrate everything. Orchestrate all the vendors.
Can you talk a little about that?
Sezin
Definitely. I think that’s—again—as you start to go modular, that’s where the maturity of the technical teams really matters.
If you have too many vendors, too many different products within your tech stack, the bigger the team you need just to manage the system. And you also need to be able to get the best out of those systems.
So you need operational teams who will demand features and functionality out of them. That orchestration is required not only in terms of system management—technical orchestration—but also operational orchestration.
You need all those business teams to be able to use the tooling you provide to deliver the customer experience at the front end. If they can’t operate the tooling, or if the tech team doesn’t know how to use it, then you’ll start to run into a lot of issues—especially with scalability, where everything sits very tightly together.
Jose
I see that. Do you have any guidance or experience on how to address that? What are some of the—I don’t know if I want to call them best practices, maybe that’s what it is—but what have been the things that really help with addressing that?
Sezin
I think the most important thing is really to know what your business needs. You need to deliver to a business strategy—not just a random stack. It’s not a shopping list of vendors or tools or technologies that you bring to the business.
You need to understand the business deeply, so they can operate it—and so you can operate it as a technical team. If you have a team of ten, fifteen people and a huge stack, it will never work. You just physically don’t have the hours in the day to maintain, manage, operate, and build on top of it.
But if you have a team that’s comparable to your tech stack, then you can operate and manage it. Orchestration becomes especially important.
Right now we’re getting closer to peak, and we’re constantly talking about how to manage peak, how to be prepared for it. And although MACH architecture makes it easier—because it’s all cloud-based, cloud-first, so it’s easier to scale and respond to peak demands—you still need to be aware of your peaks and demands.
You don’t want to run everything at its best forever. That costs a lot of money. So you need to have the knowledge and the team to operate this cloud infrastructure—and also the data, historical data, to say where we expect to be in the coming season so you can be prepared.
And tools like Queue-it, or queuing mechanisms, become really important for architectures where you have a mix of monolith and MACH.
So part of the system can handle the load, but the other part cannot. And even though that might not take the rest of the architecture down, customers still can’t use the systems. So those mechanisms help a lot to be prepared for the peaks you’re creating yourself—through promotions, through marketing communications.
You have a rough idea of when they’ll start, when they’ll happen.
Jose
I think when you mentioned at the beginning—around making sure you know what the business needs and you’re aligned with that—it reminded me of a time in another role I had, in a different job.
We built a really wonderful platform that, from a technology perspective, was great. But then we were like, “What’s going on? Why isn’t anyone using it?”
It was kind of the reverse of that. I think maybe we started from the wrong side of things. We started with, “What’s a great platform out there?” And in the end, it actually was useful for the business, but we just weren’t communicating it well enough.
So yeah, thinking about the business—that will always make your life easier from a technology perspective.
Sezin
Yeah, that is super important. You don’t need best-of-the-best all the time. And to be honest, most of the time, you don’t need that.
What you need is a stack you can operate—and that aligns with the business’s needs.
Jose
If people are considering going from a monolithic architecture toward a MACH architecture, what would you say are the benefits they can expect—or that they hopefully will be able to reap?
Sezin
Well, the main thing is modularity. You’ll have lots of modules, lots of little pieces you can release independently.
So, if you want to change one single page, you can simply release that one page. You don’t need to package everything, run regressions for weeks, then release it as a whole—and wait for something to go wrong.
That’s where the value of the technology comes in. That’s what was best-of-breed at the time, and we’ve moved back toward it.
There’s always this argument about MACH vendors or MACH-aligned products becoming too big and becoming more monolithic. I think that’s... well, I think we lack the right word sometimes. I’ve started to call them layered products.
Because even though they have many layers, they’re still microservices-based, API-driven—they still follow MACH principles. They just have multiple layers you might need.
That’s fundamentally different from a monolith. In a monolith, you can’t do anything without touching a completely unrelated part of the system. Whereas with MACH, you know your layers.
You can operate between those layers and make changes as needed, depending on the boundaries you’ve defined for each module.
So, the main challenge—sorry, I think that’s what you were asking, I kind of derailed a bit—the main challenge when moving from monolith to MACH is really looking at what you have and asking: do you really want to replicate it?
Most of the time, you don’t want to replicate it. That’s where companies get stuck—trying to recreate exactly what they had, but in MACH.
That takes much longer and much deeper analysis. But when you really look into it, you’ll realize there were lots of organic decisions, lots of things you don’t use anymore—some you don’t even know are still there.
I always find it easier to start from where the customer is and work backward. See what the customer is using, use your data, understand what’s actually beneficial to your end user and your business, and move those pieces to MACH, bit by bit.
There might be certain features that are used only occasionally—that’s a business decision: whether you want to kill it or move it.
Jose
But when moving from monolith to MACH, do you see it as a big-bang transition? Or is it more that you can start peeling off pieces of the monolith—start building around it—so that maybe 60% is still the old monolith, and you’re gradually adding new components?
Sezin
That is how I’ve done it every single time—start small, move the things we can move, and also show that we can do it. That’s another piece, right? In technology, there’s always a concern about whether something can be done.
Showing results builds business trust—and confidence for yourself as well, especially if you’re doing it for the first time. None of the teams I worked with were doing their third transformation. They were all doing it for the first time.
If it’s your third or fifth, you might feel more comfortable. But if it’s your first, you’ll want to gain that confidence yourself—understand the new tech stack. MACH has been around for a long time, the technologies behind it have existed, but not every engineer has used them.
So they need to learn and adapt to this new world. That will also take some time.
Jose
Kind of from that learning and adapting to the new world—and I guess reskilling in some aspects—what do you see as the most important skills in that world?
Sezin
Being open-minded. Just because someone works in technology doesn’t mean they like change—which seems contradictory, but it happens very often.
A lot of engineers use the same technologies they’ve used for a long time. They don’t necessarily want to change. They don’t necessarily want to learn something new.
Change is scary. They’re just human beings. Just because they like writing code doesn’t mean they like change.
So to me, everything is a people change. I used to appreciate that before, but as I’ve moved forward in my career, I appreciate it even more. Most of what we do is people-related. Technology simply follows.
Jose
That’s very true. Thank you for that.
Still on that point—once you do start moving toward MACH architecture, I guess you’ll face that question: “I need this component. Should I build or buy?”
There’s a decision point—do I go out and buy something off the shelf, or do I build it myself? In your experience, what’s the best way to approach that decision?
Sezin
We touched on it a little bit at the start of the conversation.
You build something if your use case is very unique—if there’s a specific reason in the business why something is done in a very different way from the rest of the market. Other than those unique cases, I don’t think you need to build much.
The rest is a buy decision—but of course, you need to consider the cost. And not just the buy cost—you also need to consider the build cost.
Jose
And when you say something “different,” are you thinking from a competitive advantage perspective? Or is it more like, “I simply can’t find a component out there that meets this specific need”?
I think of it in two different ways. But is it more about not being able to find something specific enough? Or is it more, “This is what gives us a competitive advantage”?
Sezin
Yes, there could be certain cases where it gives you a competitive advantage, and you'd want to customize.
But I think another thing to consider—especially in a MACH architecture where you have APIs and small modules you can play with—is: can you build over what you already have?
The main layer you probably wouldn’t want to get off the shelf is your front-end experience layer, because it’s very brand-driven. Each brand is different—the visuals, the tone of voice, the dynamism.
That layer isn’t something you'd just go buy a template for and use—unless you’re a corner shop. But for most of the other layers, you can often use off-the-shelf solutions, with some customization or adjustments in how systems connect.
Jose
I’d like to go back a little bit to traffic peaks—something we love to talk about on this podcast. I’ll actually read this to make sure I’m quoting it right and crediting the right people.
In doing some research, I heard Puma’s e-commerce manager, Bettina Dormes, in a podcast say something along the lines of: “Reliability is the hardest thing about composable, because every vendor has their strengths, but they often think in isolation.”
We started to touch on this earlier, and then I pulled us off course a bit. But I’d love to get back to it. In your experience—this is a more specific part of orchestration—when you're preparing for peak traffic, how do you think about that in terms of all the vendors?
Are you load testing individually with each of them? Or are you doing it end-to-end? Or both? Can you share a bit about that?
Sezin
Each vendor will do their own exercises anyway—because everyone’s getting ready for peak. And no vendor is used by just one single brand. If they go down, a lot of brands go down. Nobody’s impressed in that situation.
So they run their own tests. But as an enterprise, as a brand, we do our own tests end to end. We work with all those vendors to make sure they’re prepared and aware of what’s happening.
Of course, we don’t run these tests in production. And lower environments don’t always have the scale you need to simulate peak. So you have to talk to them, make sure they’re prepared and aware of the load testing you're doing.
It’s a full orchestration piece. We were talking earlier about the orchestration of people, vendors, the business—you need all of that to be aligned and ready for peak.
I’m a big advocate of having good account people at the vendors. For me, that’s how you choose vendors. In every layer, there are tons of vendors doing more or less the same thing.
But what really matters is: are they treating you the way you want to be treated? That’s the most important piece.
And it’s not just vendors. We have engineering partners, other partners involved too. What I always say is: we all work for one single brand. The rest is irrelevant. Everyone’s being paid by the brand we’re working for. So we all need to align and be prepared to work with each other.
Honestly, I often don’t even share who is from where. It’s irrelevant.
Jose
Still one thing on the load testing and getting ready for peak.
In my experience, and in a lot of the work we do, there's usually a bottleneck somewhere in the architecture. And I mean, I guess there will always be one, right? By definition.
But in your experience, after doing all the testing and prep, do you always know where the bottleneck is? Are you conscious of it?
Or has it happened that you were actually surprised—like, “We thought the bottleneck was here, but then we ran the event, and it turned out it was over there”?
Sezin
Yeah, I like to think of software as an organism.
You think you know where the bottleneck is—“Oh, this system always fails us,” or “There’s always an issue here.” Then you run the tests, and the interaction of certain things gives you a completely unexpected result.
In a way, that’s the fun part of software. Even if it's not the result you want, it shows you that the system has a mind of its own.
It’s physically impossible for a technology team to know every part of a system. That’s why these exercises are so important—they help you understand your system at a given time, based on the current business requirements, based on the behavior you saw during the last peak or campaign activation.
You’re constantly learning, constantly evaluating and evolving.
And to your point—yes, once you do these tests and a completely random corner of the system throws up some headache, then you have to consider:
Do we need a new solution?
Do we build it?
Do we buy it?
Do we need to scale it further?
Jose
Yeah, it's the good old theory of constraints, right? You find the bottleneck, you address it, but then—like you said, with the organism—once you improve that one area, something else comes under pressure and becomes the new bottleneck.
Sezin
Yeah, absolutely.
And then there’s the next question: how long can you keep the pressure on?
At some point, you’ll see the system is too stressed and you need to back off. I don’t know—I find these things fun.
Jose
When you said “how long,” my first thought was from a cost perspective. But that’s not what you were thinking, right?
Sezin
No, I meant actual stress you’re introducing to the system.
Say you have an activation or a campaign, and it's doing really well—like, unexpectedly well—and it just goes on for days. What happens then?
You don’t expect that behavior. You expect people to flood in, go shopping, and leave. But if they keep coming—especially if you have a global audience, across time zones—you could end up with a continuous global peak for a period of time.
Or, maybe lots of smaller peaks, but still consistently high. That can really push your system to its limits.
Jose
Still within the topic of peaks—at your previous company, Selfridges, they used Queue-it as their virtual waiting room. Can you share with us what kind of impact that had on your preparation and handling of peaks?
Sezin
It was actually super helpful. It’s funny how we started to use Queue-it.
We had it in the stack for a while, but it wasn’t in use. Then the business came and said they had an amazing celebrity activation happening in three days. And I was like, “Okay, thanks for telling me. Great to know!”
And then it was, “Okay... what do we do?”
So we had Queue-it, but it wasn’t integrated at all. And we had to do it—literally—in three days. It was, again, great fun, very unexpected, but it behaved exactly the way you want it to behave.
That’s the beauty of these new technologies. You can integrate them without a ton of hard work, and they just work.
That also connects back to my point about account relationships—how you decide who you want to work with. If you’re working with a company that isn’t willing to support you when you need help, it doesn’t really work.
Especially in retail, where everything is quick, responsive, and very seasonal. Business doesn’t do these things just for fun. They come up with these ideas because they have to.
And it’s our job—as a team, whether internal, external, third, fourth, or fifth party—to come together and find a solution.
Jose
That's a good point. And I’m sure there was a good reason they only told you three days before—and not a month before, right?
Ideally, we’d love infinite time for preparation, but that’s just not the reality.
Sezin
Yeah, absolutely. Absolutely.
Jose
I think we’re getting close to wrapping up. Are you ready for a couple of rapid-fire questions?
Don’t think too much—just share your thoughts with us.
Is there some content or resource—could be a book, podcast, or thought leader—that you’d recommend?
Sezin
There are quite a few, actually. I do love HBR—all their content, I find it really helpful.
And I’ve found it helpful at any stage of my career. They touch on everything.
From the MACH world, I really like Sana Remekie’s thought leadership—the ideas she shares and the content she produces.
And in terms of IT and content, IT Revolution is fantastic. Gene Kim and that group—who brought DORA, who brought lots of new ways of working and thinking together.
Jose
I think a lot of the books they publish—or support—are also very good. Some of those books, I think, changed... well, changed me, definitely, but also changed the industry.
So that’s awesome. Thank you for sharing that.
Do you have—if you were to give some professional advice either to your younger self or to someone starting out, maybe specifically in e-commerce or retail these days—do you have any advice you’d give them?
Sezin
I would say: be curious.
Always be curious about the domain, about the customers, the products, the ecosystem you’re in.
I’m also a big believer in being intentional. You really need an intentional approach to what to learn, where to look. You need to have an idea of what you want to achieve.
And when you bring those things together—and always consider your end user—you’ll definitely deliver good value.
Jose
Thank you. Last question.
To you scalability is…
Sezin
To me, scalability is the ability for a system to behave—without you touching it—in the right manner.
That was a strange sentence.
Jose
No, no—it was very good.
I love that different people respond to these questions in different ways. Some go straight into “It’s hard,” or “It’s complicated,” but I love that you went toward the definition—toward: “When do you know something is scalable?”
So I appreciate that. It was a very useful way to answer the question. Thank you.
And I think we’re wrapping up, so thank you so much, Sezin, for joining us. I really appreciated learning about your journey, about MACH architecture, and understanding a bit more about the e-commerce world.
Sezin
Thank you. Thank you for having me. I had a great conversation—great fun. Thank you.
Jose
And that’s it for this episode of the Smooth Scaling Podcast.
Thank you so much for listening. If you enjoyed, consider subscribing—and maybe share it with a friend or colleague.
If you want to share any thoughts or comments with us, send them to smoothscaling@queue-it.com.
This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it—your virtual waiting room partner.
I’m your host, Jose Quaresma. Until next time—keep it smooth, keep it scalable.
[This transcript was generated using AI and may contain errors.]