Skip to main content

Architecture Pattern Katas

Focused, repeatable drills designed to build fluency in style selection, topology diagramming, critique, and module-graph design. Complete each kata multiple times until the setup feels automatic.

Kata 1: Style-from-Characteristics Drill​

Time limit: 25 minutes
Goal: Given three requirement sets, pick and justify a style for each.

Setup: You will work three scenarios. For each, produce:

  • top 3 characteristics (ranked)
  • chosen style
  • one alternative style rejected
  • the first fallacy/tax that will bite if the choice is implemented carelessly

Scenario A -- Real-time inventory matcher​

A marketplace where buyers place bids and sellers' stock decrements on match. 30k matches/sec at peak. p99 latency target: 25 ms. Inventory state must not oversell. Business is the company's core revenue line. Team: 40 engineers, one veteran of a distributed-systems shop.

Scenario B -- Internal HR tooling​

CRUD on employees, time off, compensation. 200 users. Audit trail required. 3 engineers, none senior. Release cadence: weekly. Cloud budget: minimal.

Scenario C -- Multi-tenant data ingestion​

Customers drop CSV files; system parses, validates, enriches, loads into per-customer warehouses. 500 customers, each with nightly batches of 1-200GB. Idempotent stages required. 8 engineers.

Repeat until: You can produce all three decisions in 25 minutes with clear reasoning that another engineer could reconstruct.

Kata 2: Draw-the-Topology​

Time limit: 20 minutes
Goal: Draw an accurate topology diagram from a one-paragraph spec.

Setup: For each prompt, draw (mermaid, ASCII, or paper) the topology for the named style, labeling all the pieces (processes, pipes, topics, data stores, gateways, mediators, etc.) and identifying the failure mode.

Prompt 2a -- Event-driven broker topology​

"An e-commerce order checkout emits OrderPlaced; billing, inventory, and notifications each consume it. Inventory then emits StockReserved which fulfillment consumes."

Draw it. Label the broker, topics, producers, consumers. Name the failure mode if the broker is down.

Prompt 2b -- Service-based architecture with 4 services​

"Catalog, checkout, fulfillment, billing. One Postgres cluster with 4 schemas. A React UI sits behind an API gateway."

Draw it. Label services, schemas, gateway. Identify one change that would violate the style.

Prompt 2c -- Space-based architecture for concert ticketing​

"20 processing units, each with replicated in-memory seat inventory. Async data writers push to a Postgres cluster; data readers hydrate new PUs on start."

Draw it. Label PUs, replicated grid, data writers, readers, middleware, DB. Name the scenario that creates a data collision.

Repeat until: You can produce each diagram from the paragraph alone in under 7 minutes, without referring to the concept page.

Kata 3: Microservices-Gone-Wrong Critique​

Time limit: 20 minutes
Goal: Given a failing microservices description, diagnose the anti-pattern and prescribe a specific fix.

Setup: You receive a 1-paragraph description. Respond with:

  • the anti-pattern name (distributed monolith, shared-DB microservices, chatty microservices, nanoservices, no-observability, unowned service, other)
  • why it is hurting the team (2-3 sentences)
  • prescribed fix (2-3 sentences; be specific)

Description 3a​

"We have 40 services, each owning between 1-3 REST endpoints. Any new feature requires touching 4-7 services. Every request chain is 6-12 services deep. Total engineering count: 30."

Description 3b​

"Our 8 microservices each have their own schema in one shared Postgres. Reports are written as cross-schema joins. A recent schema change in the customer service broke queries in 3 other services."

Description 3c​

"We run 15 microservices in Kubernetes. A recent production incident took 4 hours to diagnose because we had to SSH into individual pods and tail logs. Traces are not implemented."

Description 3d​

"We have 12 services. To deploy the order service, we must also deploy the billing and notification services because they share a versioned proto file that was copied into each repo."

Repeat until: You can diagnose and prescribe in under 5 minutes per description without consulting Concept 11 or 12.

Kata 4: Sketch a Modular-Monolith Module Graph​

Time limit: 25 minutes
Goal: Given a domain brief, produce a modular-monolith module graph, module API surfaces, and three boundary rules.

Setup: You will receive a domain brief (pick one below). Produce:

  1. A mermaid graph of 6-10 modules with labeled responsibilities.
  2. For each module, the public API surface (3-6 method names) and what is private.
  3. Three boundary rules in actual tool syntax (pick: ArchUnit, Packwerk, import-linter, or dependency-cruiser).
  4. One cross-cutting concern and where it lives.

Domain 4a -- Tuition management system for a university​

Students, courses, registrations, grades, billing, transcripts, financial aid, reports, admin.

Domain 4b -- Ride-hailing platform (monolith version)​

Rider, driver, trip, pricing, payments, ratings, dispatch, notifications, admin, analytics.

Domain 4c -- SaaS project management tool​

Workspace, project, task, comment, user, notification, billing, integration-webhooks, reporting.

Repeat until: You can produce a complete module graph + API surfaces + 3 rules in under 25 minutes from a cold read of the domain brief.

Completion Standard​

  • You can complete Kata 1 in the time limit with decisions defensible by another engineer.
  • You can draw all three topologies in Kata 2 from memory.
  • You can diagnose the four Kata 3 descriptions without looking up the anti-pattern names.
  • You can produce a full module graph + boundary rules for one Kata 4 domain in the time limit.
  • You have done each kata at least twice with different choices or domains.