I Lost Two System Design Interviews in Two Weeks. Here's the Cycle Built From What I Got Wrong.
A four-month cycle on system design, written for analysts who are watching the senior BA role shift under their feet. Eight publications, one OMS case, every two weeks.
Part 0 of the SA System Design Cycle. Next: Problem Framing. Also published out of order: Discovery.
Two interviews, two weeks
A week ago I sat through a system design interview at Tabby. The role was Senior System Analyst, described in the job posting as “platform architecture and service interaction design across product services and CoreBank components.” I did not get the offer.
Two weeks before that, BrainRocket in Portugal. Same kind of session - the job description had said “requirements gathering, system design, and process optimisation.” That round did not produce feedback at all; I never heard back on the architectural part.
I am a senior BA with 14 years across enterprise integration, multi-brand retail, and regulated reporting in EU markets. I do not call myself a solution architect; I have deliberately not pursued that title. But the last twelve months I have been standing exactly on the seam between BA work and architecture - the seam where the JD describes one role and the interviewer asks for another, where stakeholders expect requirements while the team already wants component diagrams. I have stood there sometimes badly, as Tabby and BrainRocket made clear in different ways. This cycle is what I have learned by failing to answer the questions I should have anticipated.
Across four senior BA interviews in twelve months, two turned into full architecture sessions. Half the room.
Both times I made the same mistake.
I started drawing.
What going wrong actually looked like
I did not panic. I have built things. I leaned on platforms I have actually worked with at Metro Cash & Carry, where the OMS handled around 50 distinct order processes and roughly 200 routing rules.
That kind of complexity does not survive without practitioners who own pieces of it. The analysts I worked with there - Aleksey Andreev and Vyacheslav Kachalov - and Pavel Ryukhov on the Retail Operations side were the kind of people who could trace an order through that system from capture to fulfillment in their head. They did not have to look anything up. The routing logic was not in a wiki page; it was in their hands. I learned a lot of what I think I know about OMS by watching how they reasoned about edge cases.
So at Tabby, when the marker went on the whiteboard, I drew based on that. Order capture, orchestration, inventory reservation, status tracking. I asked clarifying questions as I drew - what kind of throughput, how many channels, what kind of consistency model.
That was the mistake. The questions should have come first.
By the time I started asking, the interviewer had already accepted my drawing as committed. He was now poking at it with sharper questions. “What do you use if you cannot use a messaging system?” I had proposed Kafka in my sketch. “How do you guarantee delivery without a queue?” “If part of your microservices fails, how do you make sure the data is not lost?”
These are reasonable senior BA questions on a real system. They are also constraints in disguise. If I had pulled them out of the interviewer at the start - “what is your team’s stance on event-driven middleware? what is your durability requirement? what kind of failure modes have you actually seen in production?” - I would have drawn a different architecture. Possibly a smaller one. Possibly with the same Kafka, but with explicit dead-letter handling and idempotent consumers as visible primitives, not as features I had to defend after the fact.
Once a sketch is on the board, you cannot un-sketch it. You can only defend it. The questions you fail to ask early become the trade-offs that ambush you later.
There is a chain underneath this, and it is worth naming because every stage of this cycle is a different link of it. Questions reveal constraints you did not know existed - constraints that lived only in someone’s head, or in a half-deprecated wiki page, or in the failure log nobody reads. Constraints define which architectures are even possible to build - some patterns that look elegant on a whiteboard simply do not fit a 12-region GDPR setup, or a legacy ERP with brittle batch windows. Architecture defines which failure modes you will live with for the next five years - the choice between event-driven and request-response is also a choice between two different categories of incidents at 3 a.m. Skip the questions, and you have committed to constraints you never saw, and to failure modes you cannot now redesign away. The cycle walks one link at a time.
The rejection that named the gap
I lost both offers.
BrainRocket simply went silent on the architectural front - one of those rejections where you do not know which leg of the interview tipped it.
Tabby’s rejection email was diplomatic and precise. Two lines stayed with me:
“At the same time, for this role we are looking for a broader systems perspective and a stronger foundation in system-level thinking and ownership. Your experience is currently more aligned with working closely under architectural guidance.”
That phrase - “working closely under architectural guidance” - is the cleanest naming of the gap I have heard from the hiring side, and I have spent a year reading rejection emails. The implication landed correctly. My center of gravity is still inside someone else’s architecture, and the role demanded a different one.
That is exactly the shift this cycle is about.
The trend the JDs hide
The senior BA role has shifted under us, and the people doing the hiring know it before we do. The job descriptions still describe a 2018 BA. “Requirements gathering, process optimization, stakeholder management.” That language lets a candidate opt in or out of architectural thinking. The interview reveals which one you did.
I checked whether this was just my pipeline. It is not, and the way it is not is more interesting than the headline suggests.
emagine in Warsaw is hiring a “System Analyst/Architect” for a banking project. The first responsibility on the list is “design and document high and low-level architecture for applications.” The role title itself fuses analysis and architecture into one path - that is the structural tell, and it is becoming more common in EU postings.
UnitedHealth restructured Senior BSA responsibilities into five categories. One of them is now “Solution Design & Delivery” - equal weight with “Business & Systems Analysis.” The work that used to be the entire job is now one of five.
These are two cleanly worded postings. There are more like them. But I want to be honest about what the search showed: most senior BA postings still do not ask for “system design” in plain language. They ask for “translate requirements into specifications,” “support architectural decisions,” “drive design process.” Those phrases let candidates opt in or opt out, and they let interviewers test for more than what the JD signals.
The interview has already shifted. The job posting has not caught up. A candidate who prepares only against the words in the JD walks into the room unprepared for the whiteboard. That is the gap. That is what Tabby and BrainRocket were measuring, and it is what most analysts are not yet measuring on themselves.
Why this is happening
Some of it is AI eating routine BA work. The first draft of a BRD or use case spec used to take a senior analyst a day. Now it is a 10-minute review of a Claude or ChatGPT output. The leverage in the role has moved upward, into the work AI cannot do well - predicting failure modes you have not personally seen yet, and holding a whole system in your head long enough to weigh what the architecture will cost you in maintenance in year three.
Some of it is structural. Modern stacks are integration-heavy. Microservices, event-driven, headless commerce. You cannot write a useful requirement in a world like that without understanding how it will be implemented - or at least being able to challenge the proposed implementation when it conflicts with what you actually need. The clean split between “BA writes WHAT, architect writes HOW” works in waterfall projects with three-month spec phases. Those are getting rare.
The role survives the squeeze in one shape: a senior BA who can frame the problem with stakeholders, design the system at a level that hands off cleanly to engineering, and stay engaged through implementation. The role that does not survive the squeeze is the one Tabby was politely declining to hire.
Who this cycle is for
A word on who this is for, because long-form writing is expensive on both sides and I would rather you self-select out early than feel mismatched at article four.
This is not a course for juniors learning their first BRD - the cycle assumes you have already written specs, run discovery sessions, and can read a sequence diagram without translation. It is also not for solution architects who already own the architectural seat - you will know more about the technical patterns than I do, and the cycle is not for you. It is for senior BAs and SAs who can feel the role pulling toward architecture, who have started getting whiteboards in interviews, and who have noticed that the JD did not warn them about that shift. If you have already been there - the cycle is the path I wish someone had laid down before I sat at Tabby.
The cycle
I am writing a cycle. Eight publications, one every two weeks, finishing in mid-August.
The case is OMS - order management for a multi-brand retailer, three brands, a zoo of legacy systems (different ERPs, different marketplace integrations, different fulfillment partners). The business wants one unified platform. This is the exact shape of problem you get on a senior BA interview if you work in retail, e-commerce, or B2B platforms, and it is the exact shape of problem analysts solve in real projects every quarter.
I picked OMS because it is the right size. Large enough to expose every stage of system design. Niche enough that the public canon has not already over-explained it. Most system design content uses the same three or four examples (Twitter, URL shortener, ride-hailing) and developers have already read them. OMS gives us new ground.
Seven stages, one case, end to end:
- Problem Framing - the questions before any diagram. Stakeholder map for three brands. System boundaries.
- Discovery - functional and non-functional requirements. Why “10 orders/sec” and “10K orders/sec” lead to different architectures.
- Constraints - legacy ERPs, budget, brand-specific teams, compliance. The diamond between ideal and realistic.
- High-Level Design - architectural style. C4 Context plus Container. The central conflict of multi-brand: what is shared, what is brand-specific.
- Data and LLD - order entity, multi-tenant model, OpenAPI fragments, sequence diagram for checkout.
- Validation - threat modeling, “what breaks first?”, PoC candidates. The honest list of what we still do not know.
- Handoff and Support - ADRs, diagrams, RACI for handoff to dev/QA/DevOps. Change management when reality contradicts the design.
By the end of these eight articles, the goal is concrete and measurable in your own work. You will be able to walk into a system design interview and ask the framing questions before the marker touches the board. You will be able to defend a trade-off you made under pressure instead of accepting one quietly handed to you. You will know where AI accelerates this work and where it produces plausible diagrams hiding broken constraints. And you will have a working mental model of how a senior BA hands off architectural intent to engineering without losing the design in translation. That is the contract; if it does not match what you are after, this is the right point to stop reading.
Each stage will have a short sidebar on AI: where it actually helps on that stage, where it generates plausible-looking nonsense, what part of the work cannot be delegated. One example from last week, to make this concrete: I asked Claude to draft an OMS architecture for a multi-brand retailer. It produced clean C4 Context and Container diagrams, accurate enough that I almost accepted them. Then I noticed it had silently treated cross-channel inventory consistency as a free property of the design - no synchronization protocol, no eventual consistency window, no reconciliation job mentioned anywhere. That assumption would have shipped to production unnoticed if a human had not pulled the diagram apart and asked “how does this actually stay consistent?” AI is good at the diagram. It is weak at the constraint behind the diagram, and the constraint is where the system breaks. The most common question I get from analysts is not “should I use AI” - it is “where exactly does it stop being useful.” The cycle answers that question stage by stage.
A note for new readers: my previous piece Error Handling as a Design Decision (April 2026) was the unintentional pilot for this cycle. It applied the same lens - “what is a senior BA’s responsibility when designing the failure path?” - to one specific decision. The reception convinced me the broader cycle was worth writing.
Two questions
If you are a BA or SA and your last interview included a system design task - what was the part where you knew you were sliding? The questions you did not ask, the architecture you could not justify, the trade-off you missed?
If you are hiring senior BAs - what is the gap between candidates and the role you are trying to fill? I want the cycle to address real gaps, not theoretical ones.
The first stage publishes in two weeks. We will start with the questions a senior BA asks before drawing a single box - the questions I should have asked at Tabby and BrainRocket and didn’t.
Next in the cycle: Problem Framing — Clients Don’t Know What They’re Asking For.