A team designs a ticket-booking service for a regional festival. It handles the expected load comfortably, and the design review ends with nods. Then the brief changes: the organiser now promises that ticket sales must keep working even if one data centre goes offline during the on-sale window. The same design now has a single point of failure, and the engineers who drew it have to decide what to change, what to give up and how to explain the choice.
This is an illustrative scenario, not a documented incident. It is the situation a system design kata is built to rehearse: a design that was fine under one set of constraints meets a new one, and engineers must defend or revise it with reasons. This guide is for engineering enablement leads and engineering managers. It covers what a system design kata is, how to build one, how to run and score it, and where training stops being the answer. Every case and criterion should be validated by a senior engineer before you use it.
What is a system design kata?
A system design kata is a short, time-boxed design exercise. A small team receives a one-paragraph business problem, sketches an architecture, presents it to peers and answers hard questions. Searchers also call it an architecture kata or an architectural kata. The format was started by Ted Neward as a workshop and is documented, with its rules and the moderator role, on Neal Ford's architectural katas page. Neward's motivating question, quoted there, is how organisations are supposed to grow great architects when engineers get the chance to architect fewer than a half-dozen times in a career. A kata gives them extra repetitions without production risk.
त्वरित तथ्य
| सवाल | संक्षिप्त जवाब |
|---|---|
| What is the task? | Defend an architecture when a constraint changes. |
| How big is a group? | The original format uses small groups of 3 to 5 people, with a moderator. |
| What do you score? | Trade-off reasoning and the response to a new constraint, not the prettiest diagram. |
| Is a quiz on design patterns enough? | No. It confirms prerequisites, but not whether an engineer can justify a choice under pressure. |
| Who validates the case? | An engineering manager or a senior architect. |
| What can a kata not fix? | Missing design authority, unclear requirements and no time to design properly at work. |
| How do you know it worked? | A new, unseen case scored against agreed criteria, plus follow-up on real design reviews. |
1. Describe the performance problem
Start with the task, not the topic. The task is to defend an architecture under changing constraints. In real work this happens in design reviews, incident follow-ups and planning meetings where a requirement moves: more traffic, a stricter availability promise, a new data-residency rule, a tighter budget.
Many engineers can draw a sensible architecture. Fewer can say what they would trade away when two goals collide and what evidence would change their mind. That second skill is what the kata practises.
Write a one-sentence performance statement and have an engineering manager check it: "Given an architecture and a changed constraint, the engineer names what breaks, proposes a change, states the trade-off and says what they still do not know."
2. Diagnose the learning and context gaps
Before building anything, compare the task with what your programme practises and assesses today.
- Does practice use the real task? If training teaches patterns in isolation and assessment is a multiple-choice test, nobody has practised defending a choice.
- What is the cognitive demand? In Bloom's revised taxonomy, comparing options against constraints sits at analyse and evaluate, and proposing a revised design reaches create. Our guide to ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना shows how to match the activity to that level.
- Is something other than skill in the way? Check whether engineers have time to design, whether anyone owns architecture decisions and whether requirements are written down. If a decision is made by someone outside the team, no kata will change what the team can do. Pass those causes to the people who can fix them.
3. Design preparation and practice
Give each stage a distinct job.
तैयार करना। Check prerequisites with a short diagnostic: the vocabulary your team uses (availability, consistency, latency, cost), the building blocks they are expected to know, and your own design review template. Self-paced study suits this stage, and a recall check confirms prerequisites only.
अभ्यास करें. Run the kata itself. In the format described on Neal Ford's site, after the team forms, the exercise runs in three phases: a discussion phase where the team works out what it is building, a peer review phase where each team presents and answers questions, and a voting phase where peers give a thumbs up ("nailed it"), a thumbs "meh" ("missed a few things") or a thumbs down ("missed it, badly"). Some rules are worth borrowing directly: teams may make assumptions about unfamiliar technology but must state them, and may not assume they can hire a team of all-stars.
Add the changing constraint. The standard kata gives a fixed problem. To train the skill in this guide, add a second card halfway through: a changed constraint the team must absorb. This is a design choice of ours, not part of the original rules, so pilot it.
प्रतिक्रिया। Link feedback to decisions, not to a total score. "You moved to two regions, but did not say what happens to an order placed during the switch" is more useful than "3 out of 5".
Live input or asynchronous review? Live facilitation adds most when a choice is ambiguous and engineers learn from a senior colleague explaining why they would hold the line. Asynchronous review is enough for comparing a written rationale with an annotated example.
4. Work through a realistic example
Illustrative. A senior engineer should validate the case and the answer criteria before use.
मामला। A regional festival sells 20,000 tickets over a weekend, with most sales in the first ten minutes. The first version of the brief asks for a booking service that copes with that peak. The design: one web tier, one database, a payment provider call at checkout.
The changed constraint. Halfway through, the organiser adds: sales must continue if one data centre goes offline, and no ticket may be sold twice.
A first attempt. "Add a second data centre and replicate the database." The team has reached for a familiar component, but has not said what happens to the no-double-sale rule when the two sites cannot talk to each other.
प्रतिक्रिया दें और पुनः प्रयास करें। The facilitator asks the team to name the two goals in tension and which one they would protect in a network split. The retry asks them to choose and to say what the customer experiences.
A stronger attempt. "We would protect the no-double-sale rule. During a split, only the primary site sells tickets and the other site shows a waiting page. We accept lower availability for a short time to avoid selling the same seat twice. We have assumed the split is rare and short, and we would want the organiser to confirm that a waiting page is acceptable. If they need both sites selling, we would allocate separate seat blocks to each site in advance, at the cost of some unsold seats." Notice that this answer names the conflict, picks a side, states the cost and flags what it does not know.
Why each response is defensible or incomplete. Judge each against approved criteria, not against a reviewer's preferred architecture. The first attempt names a component but no trade-off. The stronger attempt is specific, states its assumptions and offers an alternative with its price.
5. Assess capability and plan transfer
Evidence of capability is performance on a new case the engineer has not seen. Score trade-off reasoning and the response to a new constraint. A simple rubric uses a 0 to 2 scale per criterion:
| कसौटी | प्रत्यक्ष साक्ष्य |
|---|---|
| कार्य निष्पादन | Defends the architecture under the changed constraint and records the evidence behind the decision. |
| विचार | Explains the relevant constraints, the alternatives considered and what remains uncertain. |
| सीमाएँ | Follows approved design procedures and asks for help when information or authority is missing. |
Anchors: 0 is absent or unsupported, 1 is partial with relevant omissions, and 2 is complete and justified against the agreed criteria. Define critical errors separately, such as ignoring a stated safety or data-protection requirement, so an overall score cannot hide one. This rubric is a proposal, not a validated readiness standard: adapt it with an engineering manager and pilot it. Our guide to designing interactive practice with useful feedback covers how to write feedback that links to decisions.
Plan transfer deliberately. After the kata, ask each engineer to bring one live design decision to a review and apply the same questions. A blameless review of a past incident is another good bridge to real work; see our guide to running blameless incident reviews.
जहां इंटरैक्टिव डिलीवरी मददगार होती है
Interactive formats help where everyone should commit before they see the group. In a live kata session, a facilitator can show the changed constraint, ask every team member to type the trade-off they would make and why, then reveal the spread before the discussion starts. The peer vote at the end of the original format is easy to run the same way. The same case can run self-paced for preparation or for engineers who miss the session. AhaSlides supports interactive learning and moving between live and self-paced delivery. It is a presentation and learning tool, not a place to draw or run architecture, so keep diagrams on a whiteboard or in your design tool. Check any specific authoring, feedback or reporting function you plan to rely on against your own workflow. For guidance on choosing formats, see our article on अनुकूली, इंटरैक्टिव और लाइव लर्निंग का उपयोग कब करें.
जो परिवर्तन हुआ उसे मापें
Decide in advance what would show that engineers can defend an architecture under changing constraints. Compare trade-off reasoning on an unseen case with a baseline taken before the programme. Define who is included, the denominator and the timing. If results improve, look at what else changed in the same period, such as a new design review template, a staffing change or an incident that raised attention, before crediting the training.
वे बाधाएं जो बनी रह सकती हैं
- Design authority. If the team does not make the decision, practising it has limited effect.
- पहर। A kata takes hours; real designs take weeks and involve data a kata cannot supply.
- Case coverage. One case exercises a few trade-offs. A score does not describe an engineer's judgement in general.
- जटिलता। More complexity is not necessarily a better architecture, so do not reward the most components.
- स्थानांतरण। Doing well in a workshop is not the same as doing well in a tense review, so check performance after the kata, in the real setting.
Name these to sponsors early and plan separate fixes. A kata improves what engineers can explain and defend. It does not create the authority or the time.
ज़्यादातर पूछे जाने वाले सवाल
What is a system design kata?
A short, time-boxed design exercise where a small team sketches an architecture for a business problem, presents it to peers and answers challenging questions. It is also called an architecture kata.
How many people should be in a team?
The original format uses small groups of 3 to 5, usually as one of 4 to 10 groups in a room. Use groups small enough that everyone speaks.
How do you assess a system design kata?
Give a new case and score trade-off reasoning and the response to a changed constraint against agreed criteria. A peer vote is useful feedback but not a score on its own.
कहा से शुरुवात करे
Pick one recurring design decision in your organisation and write a one-paragraph case around it. Add a changed constraint, have an engineering manager validate the case and the answer criteria, and draft a three-criterion rubric with a list of critical errors. Pilot it with one team before you roll it out.
To see how a kata could run live with your own team, and be reused self-paced afterwards, explore AhaSlides.
