Tag: Enterprise Architecture

Every Architecture Decision You Skip Recording, You Pay For Twice

What missing ADRs cost when you build a Dynamic Real-Time Query Engine — not Slack archaeology

When a new requirement lands, we open the Architecture Review Board (ARB).

Someone says “buy another CRM tool.” Someone says batch is fine. Someone says “we already decided this.” Nobody can find where.

That is not a tooling problem. It is a memory problem — and on a live gaming platform, forgotten decisions become production incidents, re-opened fights, and sprints that undo last year’s work.

Architecture Decision Records (ADRs) are how you stop paying twice. Not bureaucracy. Insurance.

This article is not “what is an ADR” from a textbook. It is a consequence map: decisions we made on a real gaming platform — Dynamic Real-Time Query Engine for CRM and ML, lobby and live tables, wallets, caches, fraud on the hot path — and what broke when we did not record them (or recorded them in Slack and lost them).

ADR in one sentence (before the horror stories)

An ADR is a short, durable note: what we decided, why, what we rejected, and what we will revisit. It lives in the repo or architecture wiki — not in a thread that scrolls away.

You do not need one ADR per line of code. You need one per decision that will be fought again if nobody wrote it down.

The decisions that deserved an ADR (gaming platform)

On our platform, these were not “nice to have.” They were forks in the road:

Decision	Why it mattered
RTQE as platform, not CRM patch (Cassandra + JSON DSL + shared API)	Millisecond behavioral queries for CRM and ML — one live truth
JSON DSL vs open SQL on RTQE	CRM self-serve segments without unbounded queries
REST for lobby, WebSocket for live play	Door vs room — different conversation shapes
Hazelcast for table state, Redis for leaderboards	CAP — coordination vs eventually-fresh reads
One writer per ledger	No duplicate wallet paths during strangler migration
Fail-open vs fail-closed on fraud	Block play vs allow play when the engine is down
Reuse Spark / buy EMR vs build segmentation	Cost and ownership on offline compute
Strangler order: transactions before lobby split	Plateau sequence — not big-bang weekend

Each of these showed up in ARB, stand-up, or a new squad’s first design doc. When we missed recording one, we paid a predictable price.

If you miss the ADR — consequences (with examples)

1. Dynamic Real-Time Query Engine — “let’s bolt another tool onto CRM”

Decision: Build the Dynamic Real-Time Query Engine (RTQE) as shared platform infrastructure — not a one-team patch. Cassandra time-series (one table per event type), JSON DSL for behavioral segments, REST APIs for CRM, targeting, and the ML Service — millisecond queries while the player is still on screen.

If you skip the ADR:

CRM buys or builds a narrow segmentation tool; ML spins up a second live-events pipeline.

Consequence: duplicate stores, segments that lag live play, engineering tickets for every new behavioral question — “real-time” becomes tomorrow’s batch.

Symptom in prod: offer fires after the player left the table; CRM and ML disagree on the same player’s last hour.

What the ADR should have said: Platform not patch. One engine, many consumers. Bounded JSON DSL — not open SQL. Cassandra model: player_id partition, time-series clustering, one table per event type.

2. RTQE query model — “just expose SQL to CRM”

Decision: JSON DSL with bounded query models (aggregates, time windows, expressions) — every query maps to a single-partition, time-bounded Cassandra read. Not open SQL to marketing tools.

If you skip the ADR:

Someone exposes read-only SQL “for flexibility.”

Consequence: unbounded scans, hot partitions, on-call pages during a campaign launch — CRM “self-serve” becomes production roulette.

Symptom in prod: segment job takes 30 seconds; player already churned; CRM blames “the real-time engine.”

What the ADR should have said: DSL not SQL. Query bounds by construction. `searchTime` aligns with time-series clustering key.

# ADR-001: Dynamic Real-Time Query Engine as shared platform (not CRM patch)

Status: Accepted  
Date: 02/15/2025
Deciders: Architecture Board, CRM, Data Platform, ML, VP Engineering  

Context

CRM and marketing needed to understand live player behavior and act while the player is still on screen  not via nightly batch jobs. Existing CRM tools could not answer behavioral questions in milliseconds. The easy path was another point solution on the CRM stack; the harder path was shared platform infrastructure.

 Decision

Build the Dynamic Real-Time Query Engine (RTQE) as a foundational building block:

 Apache Cassandra — one table per event type, time-series keyed by `player_id` + event timestamp
 JSON DSL — bounded behavioral queries (aggregates, time windows, expressions) — not open SQL
Event ingest pipeline — decoupled producers into the engine (point-to-point queues)
 Java 21 + Spring Boot — REST APIs for CRM, targeting, and ML Service consumers
Platform scope — same engine serves multiple consumers — not a single-team patch

Consequences

Positive: Millisecond segments on live play; CRM self-serve in JSON; ML gets real-time features from one pipeline; ~100K req/s headroom with virtual threads and horizontal scale.

Negative: Custom DSL to maintain; Cassandra modeling discipline required; platform team owns SLAs for all consumers.

Obligations: Query bounds by construction; one-table-per-event-type schema governance; document rejected “SQL over everything” and “CRM-only tool” paths.
| Alternative | Why rejected |
|-------------|--------------|
| Bolt-on CRM segmentation tool | Solves one team;  duplicate pipelines for ML; batch mindset |
| Expose raw SQL to CRM | Unbounded queries; safety and ops risk on hot path |
| Single generic events table | Partition and query unpredictability; fights Cassandra strengths |
| Nightly batch only | Misses the conversion window — player already left |

3. REST lobby + WebSocket game — “let’s poll matchmaking from the socket”

Decision: REST (or HTTP API) to Lobby — find and join a table. WebSocket to Game — live play, broadcast state.

If you skip the ADR:

Mobile team polls lobby state over the game socket every 500ms for simplicity.

Consequence: socket fan-out load explodes; matchmaking logic bleeds into game shards; you cannot scale browse traffic separately from seated players.

Symptom in prod: lobby spike during a tournament drags down live tables — the failure domain you split on purpose.

What the ADR should have said:Door = REST. Room = WebSocket. Do not merge because one client library is easier.

# ADR-002: REST for lobby (door), WebSocket for game (room)

Status: Accepted  
Date: Migration Plateau 2  
Deciders: Mobile, Lobby, Game squads, ARB  

Context

Matchmaking is request/response: find table, seat player, return connection info. Live play is a long-lived session: broadcast state, play events, timers. Mixing both on one channel couples browse traffic to seated-player scale.

## Decision

REST (HTTP API) to Lobby Service for matchmaking, presence, seat assignment.
- WebSocket to Game Service for live table play after seat confirmed.
- Session handoff: lobby returns game shard / token; client opens socket to game fleet.

## Consequences

Positive: Scale lobby on browse traffic independently; clear failure domains; matches client mental model (door vs room).

Negative: Two client integrations; handoff bugs if token/session contract drifts.

Obligations: Document handoff flow in API spec; integration tests for seat → connect path.

 Alternatives considered

| Alternative | Why rejected |
|-------------|--------------|
| WebSocket for lobby polling | Fan-out and unnecessary persistent connections for short requests |
| REST for live play | Polling latency unacceptable for table state; wrong conversation shape |
| Single monolith socket | Failure domain and scale coupling we were leaving |

4. Hazelcast vs Redis — the annual CAP debate

Decision: Hazelcast (remote cluster, sync backup, CP locks) for recoverable table state when a game node dies. Redis (cluster) for leaderboards where slightly stale ranks are acceptable.

If you skip the ADR:

Every new hire proposes Redis for everything or Hazelcast for “leaderboards too.”

Consequence: quarters lost to benchmarks and slide decks; wrong tool on wrong workload; wallet or pot state in a cache that was never meant to be the ledger.

Symptom in prod: failover restores the wrong pot; leaderboard shows ranks from before a partition.

What the ADR should have said:HZ = coordination + recovery (lean C). Redis = high-read scores (lean A). Money still flows queue + DB.

# ADR-003: Hazelcast for table recovery, Redis for leaderboards

Status: Accepted  
Date: Post modularization scale-up  
Deciders: Platform ARB, Game squad  

 Context

Game nodes are pinned per table with local active state. On node death, we must recover pot, seats, and turn without split-brain. Leaderboards are high-read, tolerate slight staleness, and do not need CP semantics for every rank update.

 Decision

Remote Hazelcast cluster (six members, clients only from game/lobby services): `IMap` with sync backup for table snapshots; CP locks + fencing on failover.
Redis cluster (three nodes) for leaderboards reads/writes — eventual consistency acceptable for ranks.
Wallet ledger stays queue + database — not in either cache.

 Consequences

Positive: Correct recovery for live money tables; leaderboard scale without HZ partition pressure on every rank tick.

Negative: Two cache platforms; clear ownership required per workload.

Obligations: Failover drills; monitor backup lag; no dual writers on game state.

Alternatives considered

| Alternative | Why rejected |
|-------------|--------------|
| Redis for table state | Wrong CAP fit for pot recovery without careful fencing; risk of split brain |
| Hazelcast for leaderboards | Overkill; CP cost not justified for ranks |
| Embedded HZ in game JVM | Blast radius; fleet churn reshapes grid |

5. One writer per ledger — “we’ll dual-write during migration”

Decision: During strangler migration, only Transaction Service writes the wallet ledger. Monolith wallet path must decommission, not linger “just in case.”

If you skip the ADR:

Plateau 1 ships with two writers — monolith and new service both mutate balance.

Consequence: race conditions, support tickets (“where did my chips go?”), reconciliation nightmares, audit failure.

Symptom in prod: player balance disagrees with ledger after a hand — the gap ArchiMate was supposed to close.

What the ADR should have said:One writer per ledger. Coexistence duration named. Decommission rule in the same doc as the migration ADR.

 ADR-004: One writer per wallet ledger during strangler migration

Status: Accepted  
Date: Plateau 1 (transactions strangler)  
Deciders: Transactions squad, Platform ARB, Risk  

 Context

Extracting Transaction Service while the monolith still serves lobby and game creates a coexistence window. Dual wallet paths are tempting for “safety” but produce race conditions and audit gaps.

 Decision

Transaction Service is the sole writer to the wallet ledger after cutover.
Monolith in-process wallet mutation 
decommissioned by named date — not left dormant. Coexistence: read paths may dual-serve briefly; writes do not.

 Consequences

Positive: Auditable ledger; support can trust one source of truth; strangler gap closes cleanly.

Negative: Requires feature flags and migration testing; rollback plan must be explicit.

Obligations: ADR linked in ArchiMate gap P0→P1; reconciliation job until decommission complete.

Alternatives considered

| Alternative | Why rejected |
|-------------|--------------|
| Dual-write monolith + service | Race conditions; “where did my chips go?” tickets |
| Big-bang cutover weekend | Unacceptable downtime risk for live tables |
| Ledger in game cache | Violates money-off-hot-path principle |

6. Fail-open vs fail-closed — fraud on the hot path

Decision: On player-facing blocks, prefer explainable decisions and clear audit. On hot-path latency, define what happens when the fraud engine is unavailable — fail – open vs fail-closed is a business choice, not a default in the SDK.

If you skip the ADR:

On-call flips behavior under pressure without a recorded principle.

Consequence: either legitimate players frozen at peak (revenue loss) or abuse runs unchecked during an outage (loss + trust hit).

Symptom in prod: incident post-mortem says “we thought prod was fail-closed” — staging was fail-open.

What the ADR should have said:Gameplay path: [X]. Wallet path: [Y]. Owner: Risk + Platform. Review when SLA changes.

# ADR-005: Fail-open vs fail-closed on the fraud hot path

Status: Accepted  
Date: Fraud engine Phase D (Technology Architecture)  
Deciders: Risk, Payments, Platform ARB, Game squad  

 Context

The real-time fraud engine sits on game and payment hot paths. When the Decision API is slow or unavailable, someone must decide: block traffic (fail-closed) or allow traffic (fail-open) until recovery. That is not an SDK default — it is a business and compliance choice. Without a recorded policy, staging, prod, and on-call behave differently.

 Decision

Define a policy matrix by path and transaction type — documented, tested, and owned by Risk + Platform:

| Path | Default when engine unavailable | Rationale |
|------|----------------------------------|-----------|
| Gameplay / join table | Fail-open with rate limits + post-hoc review | Revenue and player experience at peak; friction on outage freezes live tables |
| Wallet / buy-in / payout | Fail-closed (or queue + async settle with hold) | Money movement requires audit; abuse during outage is unacceptable |
| High-value withdrawal | Fail-closed always | Chargeback and regulatory exposure |

Cross-cutting rules:

Explainable reason codes required for any player-facing block when engine is healthy  
Shadow mode in migration — score beside legacy; do not enforce until false-positive SLA holds  
Break-glass override with Risk RACI — not an undocumented on-call toggle  
Same matrix in staging and prod — no silent drift  

 Consequences

Positive: Incidents have a playbook; no “we thought prod was fail-closed”; ARB can govern Phase G against a written matrix.

Negative: Fail-open on gameplay accepts temporary abuse risk — must pair with velocity caps, DLQ review, and post-incident replay.

Obligations: Latency budgets measured; policy matrix in runbooks; ADR linked from Decision API config and ArchiMate technology constraints.

Alternatives considered

| Alternative | Why rejected |
|-------------|--------------|
| One global fail-closed | Legitimate players frozen at peak; revenue loss during engine blip |
| One global fail-open | Wallet abuse during outage; audit and trust failure |
| On-call decides per incident | Inconsistent behavior; post-mortem blame without policy |
| Hard-code in payment service only | Game path undocumented; six squads, six truths |
| Vendor SDK default | Business policy hidden in library; not governed by ARB |

7. Build vs buy vs reuse — “let’s build our own Spark”

Decision: Reuse Apache Spark for offline segmentation; buy managed EMR where the bill fit; build only the thin control plane (scheduling, tenancy, guardrails) — not a second distributed compute engine.

If you skip the ADR:

A squad starts a 10-month “lightweight batch engine” because EMR “felt expensive” on one slide.

Consequence: duplicate platform, no hiring market, security review from scratch — savings illusion.

Symptom in prod: two batch systems, neither owned; CRM segments diverge from real-time truth.

What the ADR should have said:Reuse Spark. Buy EMR when TCO wins. Build only orchestration we cannot buy.

# ADR-006: Build vs buy vs reuse for offline segmentation (Spark)

Status: Accepted  
Date: Phase E (Opportunities & Solutions) — after RTQE platform  
Deciders: Platform ARB, Data Platform, CRM, Finance  

 Context

CRM needed offline behavioral segments that aligned with the Dynamic Real-Time Query Engine — same player truth, batch scale for campaigns and analytics. The commodity capability is distributed batch compute. The enterprise question was not “Spark or not Spark” but reuse the engine, buy managed EMR, or build a custom runtime.

 Decision

Compose — do not pick one label for everything:

| Choice | What we chose | What it means |
|--------|---------------|---------------|
| Reuse | Apache Spark | Offline segmentation engine-  commodity distributed compute; do not reinvent |
| Buy (evaluated) | Amazon EMR — not selected for this workload | EMR scales; for our utilization pattern the bill was ~10x a lean in-house runtime |
| Build | Thin control plane only | Spark master on EC2 (published IP); worker pods autoscale; custom scaler (5‑min warm-up, min/max per job); ~10 days to deliver |

Rules recorded:

Reuse what is commodity (Spark). Buy when TCO and operating model both fit. Build only the layer that turns reuse into enterprise fit — not a second batch engine.
Offline segments must trace to the same event semantics as RTQE — no shadow data estate for CRM.
Owner: Data Platform operates runtime, scaler, and upgrades.

 Consequences

Positive: ~10× lower ongoing cost vs EMR path for our pattern; delivery in ~10 days; CRM segments stay aligned with real-time truth.

Negative: We own Spark master failover, scaler logic, and security patches — not EMR’s managed boundary.

Obligations: Revisit EMR when utilization or compliance changes; document payback in ARB; no “build our own Spark” proposals without new context.

 Alternatives considered

| Alternative | Why rejected |
|-------------|--------------|
| Buy EMR for this workload | Capability fit yes; cost fit no (~10× bill for our utilization) |
| Build a new batch engine from scratch | Enterprise malpractice; no hiring market; years of maintenance |
| CRM vendor segmentation module only | Duplicate pipeline; diverges from RTQE player truth |
| Reuse Spark with no control plane | Could not meet warm-up, per-job limits, tenancy we needed |
| Buy only — no reuse/build split | Treated “buy” as slogan; ignored thin-build payback |

Strangler order — “let’s split lobby first, it’s easier”

Decision: Transactions module first via broker — money off the monolith hot path. Lobby + game split in Plateau 2. Sequence documented in migration model and ADRs.

If you skip the ADR:

Product pushes lobby microservice first because the UI team is ready.

Consequence: pretty services, money still in the monolith — the riskiest coupling untouched; false sense of “we migrated.”

Symptom in prod: “we’re on microservices” but a stuck wallet call still kills live tables.

What the ADR should have said:Plateau 1 = transactions strangler. Plateau 2 = REST lobby + WebSocket game. Link to ArchiMate gap.

ADR-007: Strangler migration order — transactions before lobby split

Status: Accepted  
Date: ADM Phase F (Migration Planning)  
Deciders: Platform ARB, Product, Game, Transactions, Lobby squads  

Context

Moving from a socket monolith (lobby + game + wallet in one deployable) to modular services tempts teams to split what is easiest first — often lobby/UI — while money stays in the monolith. That creates a false "we migrated” story and leaves the highest-risk coupling (gameplay tick + wallet) untouched. Migration order is an architecture decision, not a sprint convenience.

 Decision

Strangler sequence — documented in ArchiMate plateaus and ADRs:

| Plateau | Work package | What ships | Monolith still owns |
|---------|--------------|------------|---------------------|
| Plateau 0 | — | Baseline monolith | Lobby, game, wallet (all in one) |
| Plateau 1 | WP1 — Extract transactions | Broker + Transaction Service; one ledger writer | Lobby + game |
| Plateau 2 | WP2 — Split lobby and game | REST lobby + WebSocket game handoff | — (target modular) |
| Later | WP3+ (optional) | Shard game fleet, containerize, autoscale | Per roadmap |

Rules recorded:

1. Plateau 1 = transactions strangler first — money off the gameplay hot path before cosmetic service splits.
2. Plateau 2 = REST lobby + WebSocket game — only after Plateau 1 coexistence rules and ledger ADR (ADR-004) are met.
3. No big-bang weekend — each plateau runs in production with named gaps and decommission dates.
4. Product priority does not override sequence without new ARB context (supersede this ADR).

Consequences

Positive: Riskiest coupling addressed first; live tables keep running; board can recognize plateau transitions; aligns with ADM Phase F and Agile increments.
Negative: Lobby/UI teams wait for Plateau 2; requires patience and visible migration model so squads do not fork private diagrams.

Obligations: ArchiMate work packages link to ADR-004 (one writer) and this ADR; sprint reviews ask “which plateau does this close?”

 Alternatives considered

| Alternative | Why rejected |
|-------------|--------------|
| Lobby microservice first (UI ready) | Money still in monolith; stuck wallet call still kills live tables |
| Big-bang cutover | Unacceptable downtime; no coexistence learning |
| Game split before transactions | Money path remains on hottest failure domain |
| Target-state-only migration (skip Plateau 1) | Poster architecture; production never matches model |
| Parallel all services at once | Six squads, three buses, no decommission plan |

The pattern when ADRs are missing

What you feel	What is actually happening
“We already decided this”	Decision lived in Slack / a meeting / one senior’s head
“Why did they build it that way?”	No rejected-options trail — looks like incompetence, was often a tradeoff
“New squad, same fight”	Organizational amnesia — cheaper to write 1 page than rerun ARB
“Rollback panic”	Nobody remembers coexistence rules from migration
“Architecture is slow”	You are re-deciding instead of referencing

ADRs do not slow you down. They buy back the quarters you lose re-fighting “batch CRM vs real-time platform” — or Hazelcast vs Redis.

What to put in an ADR (minimum viable)

1. Title — e.g. `ADR-001: Dynamic Real-Time Query Engine as shared platform (not CRM patch)`

2. Status — Proposed | Accepted | Superseded

3. Context — pressure, constraints, plateau you are in

4. Decision — one clear paragraph

5. Consequences — positive, negative, what we owe ops/security

6. Alternatives considered — what you said no to and why

Length: one to two screens. If it reads like a thesis, nobody will write the next one.

Where it lives: `docs/adr/` in the repo, or wiki linked from the ArchiMate work package and the Jira epic. Same decision, three doors — one truth.

ADRs × ADM × Agile × ArchiMate

Practice	Role
ADM Phase G	Governance — decisions are controlled, not oral tradition
Agile	ADR per meaningful increment — not per sprint theater
ArchiMate	Work packages link to ADR IDs — gaps close with named decisions
ARB	Accept or reject ADRs; do not re-debate without new context

Anti-patterns (ADR edition)

Slack as ADR — searchable until it is not; context dies on scroll

ADR after the outage — post-mortem theater, not architecture

ADR per README paragraph — team stops writing them

No “superseded”— two contradictory ADRs, both “accepted”

ADR with no rejected options— future you cannot defend the call

Architecture PDF instead of ADRs — pretty, disconnected from backlog

Checklist: does this decision need an ADR?

1. Will a new squad ask “why?” in six months?

2. Did we reject something credible?

3. Does it affect money, play, or compliance on the hot path?

4. Does it sequence migration (plateau, coexistence, decommission)?

5. Will ops need to know failover behavior?

If yes to two or more — write the ADR before merge, not after the incident.

Wrapping up

On a live gaming platform, every architecture decision you skip recording, you pay for twice: once when you make it, again when someone unknowingly unmakes it.

RTQE as platform. REST vs WebSocket. Hazelcast vs Redis. One writer per ledger. Fail-open vs fail-closed. Build vs buy vs reuse. Strangler order.

None of those are secret wisdom. They are decisions — and decisions without ADRs become mysteries, then incidents, then quarters in ARB.

Record the call. Name what you rejected. Link it to the plateau.

That is EA doing its job: memory over slogans.

Note on the sample ADRs in this article (ADR-001 through ADR-007 — RTQE platform, REST/WebSocket, Hazelcast/Redis, one ledger writer, fail-open/fail-closed, build vs buy vs reuse, strangler order): they are illustrative mocks — written in real ADR shape to show context, decision, rejected options, and consequences. They are not the literal records from our Architecture Review Board. In production, your ADRs live in your repo or wiki, carry your IDs, dates, deciders, and may differ in detail — use the samples as templates, not as copies of our internal governance pack.

September 13, 2026

ADM and Agile Complement Each Other

Marry the map and the sprint a live gaming platform shows how.
A lot of people confuse ADM and Agile.

Sometimes TOGAF practitioners ignore Agile as if a good architecture slide deck ships itself. Sometimes Agile warriors ignore TOGAF as if sprints alone will sort out migration, data ownership, and enterprise governance.

Both camps lose.

If you marry both you get something better standard, beautiful results not perfect, but repeatable. Architecture that names what to change and in what order. Delivery that proves each slice before the next. On a live gaming platform, that marriage is not academic. Players, money, and latency do not wait for your methodology debate.

This article is ADM and Agile not vs. How they complemented each other when we moved from a monolith toward modular game engines, matchmaking and WebSockets, brokers, real-time query, and scale using the Architecture Development Method for the spine and Agile for the heartbeat.

Two words people treat as enemies.

	ADM (TOGAF)	Agile
Answers	Why change? Capabilities? Migration? Govern?	What ships this sprint? Inspect and adapt?
Rhythm	Iterative architecture cycle (phases A–H)	Iterative delivery (backlog → sprint → retro)
Risk when alone	Beautiful target state, nothing in production	Fast features, duplicate buses, no migration map
Together	ADM sets boundaries and sequence; Agile lands increments

One line:ADM is the map and the sequence. Agile is the engine. Gaming needs both.

Why a gaming platform is a honest test.

High-scale gaming and payments punish half-methods:

Hot paths — live tables, matchmaking, wallets — cannot wait for a yearly architecture review

Many squads— lobby, game, transactions, platform — need a shared map or they invent private truths

Migration is real— monolith → modules → brokers → analytics — not a greenfield fantasy

Change never stops— new abuse patterns, new playlists, new scale events

If ADM only works on calm HR portals, it is not Enterprise Architecture. If Agile only works on a single greenfield app, it is not enterprise delivery. A live game platform is where the marriage shows its value.

ADM phase	Agile practice	Gaming example
Preliminary	Working agreements, ADRs, DoR	Money off hot path; one writer per table; door vs room
Phase A — Vision	Epic, product goal	Modular monolith — lobby, game, transactions independent
Phases B–D	Spikes, sprint zero	REST matchmaking → WebSocket play; RabbitMQ off money path
Phase E	PI planning, prioritized backlog	Kafka when analytics needs history; Spark build vs EMR buy
Phase F — Migration	Incremental release, flags	Strangler off monolith — transactions module first
Phase G — Governance	Retro, ADRs, ARB	Hazelcast + Redis CAP choice recorded once
Phase H — Change	Continuous improvement	Fraud, RTQE consumers, fleet scale — cycle repeats

Preliminary + team working agreements

ADM:principles, scope, who owns architecture decisions.

Agile: Definition of Ready, squad charters, architecture decision records in the backlog.

Gaming example: principles we actually enforced — money off the gameplay hot path; one writer per live table; matchmaking as door, WebSocket as room; reuse enterprise events before shadow copies.

Without this marriage, every squad optimizes locally. RabbitMQ in one place, Kafka in another, REST polls for the game loop and nobody owns the seam.

Phase A (Vision) + epics

ADM:business drivers, stakeholders, target state in plain language.

Agile: product goal, epic, measurable outcomes per quarter.

Gaming example:Modular monolith so lobby, game, and transactions scale and fail independently without losing live play.” Not “microservices because Netflix.”

Phases B–D (Business, IS, Technology) + spikes and sprint zero

ADM: capabilities, application boundaries, technology standards.

Agile: architecture spikes, thin vertical slices, “sprint 0” for risky unknowns.

Gaming examples:

Business: separate gameplay from transactions capability — buy-in cannot block the tick

Applications:REST matchmaking → assign table → WebSocket for live session.

Technology:RabbitMQ for work routing on the hot path Kafka later for history and analytics ADM chose when Agile shipped which module first.

Phase E (Opportunities) + PI / roadmap

ADM: work packages, dependencies, build vs buy vs reuse.

Agile: prioritized backlog, capacity, dependency ordering across squads.

Gaming example: offline Spark segmentation ADM framed build vs EMR buy Agile time-boxed the 10-day build proof. Architecture named the tradeoff Agile proved the increment.

Phase F (Migration) + incremental release

ADM: transition architecture, coexistence, decommission rules.

Agile: feature flags, dark launch, strangler slices, no big-bang fantasy.

Gaming example: monolith → modular monolith module by moduletransactions off the game process first, then lobby paths, then scale events. Players still at tables while the map moves underneath.

Phase G (Governance) + retro + ADRs

ADM: compliance with principles, architecture board, change control.

Agile: sprint retro, backlog refinement, lightweight Architecture Decision Records.

Gaming example:Why Hazelcast for coordination and Redisfor leaderboards?logged once CAP tradeoff named so the next squad does not reopen the same fight.

Phase H (Change management) + continuous delivery

ADM: the cycle starts again when the business changes.

Agile:continuous improvement, operational learning.

Gaming example: fraud patterns, new real-time query consumers, region/zone fleet math new ADM iteration, new Agile quarters — same marriage.

What the marriage fixed (and vs)

Without the marriage	With ADM + Agile married
TOGAF-only: 18-month target PDF; production still on monolith	ADM names split gameplay vs money; Agile ships transaction handoff first
Agile-only: six microservices, three buses, no decommission plan	REST matchmaking + WebSocket room in sequenced increments
Big-bang cutover weekend; players feel the pain	Strangler migration; live tables while map moves underneath
Same architecture fight every squad, every year	ADRs + principles — CAP, brokers, build vs buy — recorded once

Without marriage — TOGAF-only smell.

18-month target architecture PDF production still on the monolith squads ignore it.

Without marriage Agile-only smell.

Six microservices in six sprints three message buses no decommission plan matchmaking polls REST for the game loop.

With marriage:

ADM says split gameplay and money and sequence the brokers. Agile ships transaction handoff via RabbitMQ in sprint N, matchmaking REST + WebSocketin sprint N+1, Kafka for BI when the business case is proveneach increment demonstrable at a live table.

Anti-patterns we said no to.

ADM once a year, Agile ignores it — architecture becomes wallpaper

Every sprint reinvents architecture — no standards, no reuse

Phase F on a slide, cutover on a panic weekend — players feel it

We’re Agile, we don’t need stakeholders — Risk, Payments, and Support still exist on gaming platforms

We’re TOGAF, we don’t need sprints — latency and competitors do not wait

Wrapping-Up

A lot of people confuse ADM and Agile Some TOGAF practitioners ignore Agile. Some Agile warriors ignore TOGAF.

Marry both.

ADM — what to change, who cares, how to migrate, what to govern iteratively

Agile — what ships this sprint, how we learn, how we improve — iteratively

On a ive gaming platform, that marriage produced standard, beautiful results — not slide-deck perfection, but map plus motion modular engines, doors and rooms for clients, brokers where they fit, real-time paths that scale, decisions recorded so the next squad does not burn the same fuel.

ADM is not the enemy of Agile. Agile is not the enemy of ADM. Confusion is the enemy. Marriage is the practice.

September 12, 2026

Build vs Buy vs Reuse

Enterprise architecture is full of technology debates that are really ownership debates.

Do we buy a managed capability? Reuse something that already exists (open source or internal)? Or build the missing piece ourselves?

Treated as slogans, those words start culture wars. Treated as an EA decision framework, they become a repeatable way to protect cost, time, and differentiation.

This article is that framework when to choose build, when to choose buy, when to choose reuse.

I will ground it with one example an offline segmentation engine that followed our Dynamic Real-Time Query Engine work so the guidance is not abstract. That example is illustrative, not the whole story. The same questions apply whether you are deciding on compute, messaging, identity, CI, observability, or a data platform.

The example is evidence. The decision pattern is the article.

The EA triangle, without the mythology

Choice What it means in EA terms

Buy Pay a vendor for a managed capability (product, platform, or cloud service). You buy outcomes and operating leverage and you buy their constraints and bill shape.

Reuse Adopt capability that already exists: open source, an internal platform, a shared service. You do not reinvent the commodity.

Build Create what you cannot get (or cannot afford / cannot customize) from buy or reuse alone — ideally the thinnest layer that unlocks fit.

Mature architecture almost never picks only one forever. The skilled move is composition .

Reuse the commodity engine.

Buy when the managed premium is rational.

Build only the control plane, integration, or scaling policy that makes the commodity fit your enterprise.

That composition is what good EA should sound like in an architecture board on Spark, or on anything else.

When to choose REUSE

Choose reuse when the capability is commodity, proven, and not where you win in the market.

Reuse when:

The problem is already solved well by open source or an internal shared platform

Differentiating on a from-scratch rewrite would be vanity, not strategy

Standards, community, and hiring markets already exist around the tool

You can accept the core abstraction (APIs, execution model) and invest above it

Do not confuse reuse with do nothing. Reuse still needs governance versions, security, support model, upgrade ownership.

One example (segmentation) Apache Spark was reuse. Offline segmentation needed distributed batch compute. Spark already owned that problem. Building a new engine would have been enterprise malpractice.

EA rule: Reuse what is commodity. Put architecture energy above it, not underneath it.

When to choose BUY

Choose buy when a vendor’s managed service is the fastest, safest path and the total cost of ownership (money + risk + headcount) beats building.

When to choose BUILD

Choose build when reuse gives you the core, buy is too expensive or too rigid, and a small, justified build creates enterprise fit.

Build when

You need customization the managed product will fight (discovery, scheduling policy, tenancy, warm-up, per-job limits).

Build time is short relative to the ongoing buy premium.

Build cost is defensible in payback (engineering spike vs years of platform fees).

The build surface is thin runtime, scaler, adapter, control plane not a rewrite of the commodity.

The capability sits on a critical path where vendor constraints become business constraints.

Do not build when

You are bored and want to re-implement Spark / Kafka / Kubernetes.

The only argument is “we are smart enough”.

Nobody will own upgrades, security, and 2 a.m. failures.

Buy is only slightly expensive and your team is already overloaded.

One example (segmentation):We built the runtime around reused Spark not Spark itself.

Spark master on one EC2, IP published to consumers.

Slaves as autoscaling container pods, joining via master IP / props on spin-up.

Baseline around 2 workers, scale to N with demand.

A custom scaler warm capacity ~5 minutes before job start min/max nodes per job.

Delivery in about 10 days

Ongoing cost far below the EMR path (10× difference for us)

EA rule : Build the thinnest layer that turns commodity reuse into enterprise fit and only when payback and ownership are real.

An enterprise decision checklist (use this in architecture reviews)

Before the board debates tools, answer these in order:

1. Is this differentiating or commodity?

Commodity → prefer reuse (or buy a managed wrapper). Differentiating → may justify build.

2. What exactly are we buying / reusing / building?

Force precision. The engine, the managed platform, and your scaler/adapter are three different decisions.

3. What is the 12–36 month bill for buy at our utilization?

Include idle, minimum footprint, support, and growth. Compare to reuse + thin build.

4. Can the managed option scale?

Assume yes until proven otherwise then judge cost and control, not myths.

5. What customization do we actually need?

List behaviors buy cannot give cleanly.

6. What is the smallest useful build, and how long will it take?

If the answer is months with unclear owners, buy may win. If the answer is days with clear ownership, build can win.

7. Who operates it after launch?

No owner → do not build. Buy or reuse through a platform team that already exists.

8. What is the exit / change cost?

Buy lock-in, reuse upgrade debt, build maintenance pick the debt you can service.

If you cannot answer these, you are not ready to choose. You are ready to argue.

This is one application of the framework useful because it shows reuse, buy evaluation, and build in the same decision. Your next board topic might be messaging, identity, or CI the questions stay the same.

How we got here real-time first, then offline

The story does not start with Spark. It starts with real-time.

We had already built a Dynamic Real-Time Query Engine a platform so CRM and marketing could understand player behavior the instant an event happened and act while the player was still on screen. Milliseconds, not nightly batch. Live segments, live treatments, a shared real-time data and query layer instead of bolting another third-party point tool onto CRM.

I wrote that journey separately the Architecture Board decision to build a platform, the stack, the trade-offs. The short version for this article we built real-time segmentation capability in-house because existing vendor tools could not do what we needed at that latency and because buying our way out of every CRM gap was the wrong enterprise pattern.

Then management asked the next question.

Real-time covers the moment the player is on screen. The business also needed offline segmentation richer, heavier, historical, warehouse-scale segment computation that does not have to finish in milliseconds, but still has to be ours to operate and affordable to run. Campaigns, deeper behavioral cohorts, reconciliation-style and batch analytics workloads extend the segmentation story beyond the hot path.

The pressure behind that ask was familiar to any EA review avoid huge cost from third-party vendors for yet another segmentation CDP-style capability we would rent forever. We had already proven we could own the real-time side. Extending to offline was the natural platform move if we chose build / buy / reuse correctly for batch compute, not by copying the real-time design blindly.

So the sequence was deliberate:

1. Build real-time(Dynamic Real-Time Query Engine) act in milliseconds stop depending on tools that were never designed for that window.

2. Extend to offline management wants an offline segment engine for the work that is batch by nature.

3. Apply build vs buy vs reuse on the offline runtime so we do not replace one vendor bill with another (or with EMR-scale spend) after we just escaped third-party lock-in on the real-time path.

Offline was not a random Spark project. It was the batch half of a segmentation platform we were already committing to own.

Context: what offline needed

We needed an offline segmentation engine bursty batch work over historical and large-scale data, not live gameplay milliseconds. Spark was the right compute model for that half of the problem.

Reuse

Open-source Spark the engine. Commodity. Do not reinvent.

Buy (evaluated)

Amazon EMR managed Spark path. It can scale. For our usage, the billing model was ~10× a lean self-run option. That failed the EA cost test.

Build (chosen for the thin layer)

Built piece Why it was build, not buy

Containerized Spark workers on a container service Control images, join. behavior, unit economics

Master on EC2 with published IP(domain) Consumer discovery the way our enterprise clients needed

Job-aware scaler |Warm ~5 mins before start; min/max nodes per job

10-day delivery Build time low enough to justify vs ongoing EMR premium

Outcome in EA language

Decision	Choice	Rationale
Compute engine	Reuse	Spark is commodity
Managed Spark platform	Do not buy (this case)	Bill ~10× despite scaling capability
Autoscaling runtime + scaler	Build	Customization + short build + cost payback

How that built runtime worked

1. Master on EC2 — stable control plane IP(domain) published to job submitters / consumers.

2. Workers as containers— pods scale out on spin-up they receive master IP. Spark props and associate with the master.

3. Scaler — warm workers 5 minutes before scheduled jobs each job declares min and max nodes.

4. Economics — sit near a small floor (often 2 workers), rise to N when the job needs it.

Build was scoped: runtime and policy, not a science project.

The same triangle elsewhere (same rules, different topics)

Once the framework is clear, you can map it onto other enterprise decisions without changing the logic:

Domain	Typical reuse	Typical buy question	Typical thin build
Messaging	RabbitMQ / Kafka (OSS)	Managed broker / streaming	Routing policies, CDC bridges, consumer platforms
Data / analytics	Spark, Flink, warehouse engines	EMR, serverless Spark, SaaS BI	Job-aware scalers, governance adapters
Identity	OIDC / standard protocols	IdP / IAM suites	Enterprise-specific policy and integration
CI / delivery	Jenkins / GitHub Actions runners patterns	Fully managed CI	Internal pipelines and quality gates
Observability	Prometheus / OpenTelemetry	Vendor APM suites	Cardinality controls, standard labels, routing

You will not always land on “reuse + thin build.” Sometimes buy wins cleanly. Sometimes pure reuse on an internal platform is enough. The point of EA is to decide deliberately, using one consistent test not to copy the Spark outcome onto every domain.

Anti-patterns enterprise architecture should stop

Buy everything— hides a bad bill behind a brand logo

Build everything — confuses engineering pride with strategy

Reuse means free — ignores upgrade, CVE, and ownership cost

It can’t scale” as a buy dismissal — often false check the invoice instead

Building the engine instead of the adapter — rewriting Spark/Kafka/K8s is rarely EA

No payback math — if you cannot compare a short build to a long managed premium, you are guessing

One example = one dogma a good Spark decision is not a mandate to avoid managed services forever

Closing: the EA stance

Reuse when it is commodity.

Buy when the managed operating model and the bill fit.

Build when a short, owned, thin layer unlocks customization and cost the vendor will not give you.

One example made that tangible for us: after we built a real-time query / segmentation engine in-house, management wanted to extend to offline to avoid another wave of third-party vendor cost. For that offline segment engine we reused Spark, skipped EMR on a 10× bill (even though EMR can scale), and built a job-aware autoscaling fabric in 10 days with warm-up and per-job min/max.

Use the example to understand the pattern. Use the checklist on the next decision whatever the domain.

That is enterprise architecture doing its job: fit over fashion, composition over slogans, framework over single-story dogma.

If you sit on an architecture board what question do you ask first differentiating vs commodity, or which logo is trending? Drop a comment.

September 12, 2026

TOGAF Is Theory Until You Apply ADM to a Real Problem

As a TOGAF practitioner, I hear the same complaint often TOGAF is too theoretical.

That is only half true.

TOGAF looks heavy when you study it as a framework. When you apply it the right way, especially through the Architecture Development Method (ADM), it becomes surprisingly simple and practical. Whenever a complex business problem lands on your desk, try following ADM. It does not give you magic answers it gives you a clear picture what matters, who owns it, what to build, what to govern, and what to change next.

In this article, I map a real-time fraud engine we built for high-scale gaming and payments onto ADM not as a certification exercise, but as a working method.

TOGAF ADM applied to a real-time fraud engine Preliminary through Phase H with requirements at the center signal → detect → decide → case → learn contrast of without ADM vs with ADM.

Why a real-time fraud engine is a good ADM proving ground

High-scale gaming and payments are a bad place for vague architecture.

Business risk is immediate (loss, chargebacks, regulatory heat, player trust).

Stakeholders disagree on “success” (risk wants catch-rate product wants low false positives; ops wants explainability finance wants cost).

Decisions sit on hot paths game and wallet flows cannot wait for a leisurely batch job.

Data is everywhere (events, payments, device, behavior, cases) and late or wrong data becomes wrong blocks.

Buy vs build vs reuse shows up hard (vendor fraud suites vs in-house rules/ML vs shared event platforms).

Change never stops (new abuse patterns weekly). Phase H is not optional poetry.

If ADM only works on calm greenfield HR portals, it is not Enterprise Architecture. A real-time fraud engine is the stress test.

ADM in one sentence (before we use it)

ADM is an iterative method to move from “why are we changing?” to “what must be true in business, data, applications, and technology?” to “how do we deliver and govern without lying to ourselves?”

You do not need every artifact. You need every phase question answered well enough to decide.

Preliminary Phase — get permission to architect, not just to code

ADM question: Are we allowed to run architecture as a controlled change, with principles and scope?

For a real-time fraud engine, Preliminary is where enterprises usually skip and later regret.

What we fixed here:

Architecture principles the engine must obey (examples prefer explainable decisions on player-facing blocks no silent irreversible wallet actions without audit reuse enterprise event sources before inventing parallel telemetryprotect PII in case files protect hot-path latency budgets).

Org touchpoints:Risk, Payments, Customer Support, Legal/Compliance, Game/Product, Data Platform, Security.

Repository / decision log: fraud architecture decisions are recorded, not trapped in Slack.

Scope fence: this cycle is “real-time fraud decisioning and case workflow for online play and payments” — not “boil the ocean AML + KYC + every analytics dashboard.”

Without Preliminary, every squad invents private fraud truth. ADM starts by making the fraud engine an enterprise concern.

Phase A — Architecture Vision name the pain and the target state in business language

ADM question: What problem are we solving, for whom, and what does success look like?

Fraud conversations love tools. Phase A refuses tools first.

Drivers we made explicit

Abuse and payment fraud leaking into loss and support load

Real-time game and wallet paths needing decisions in tight latency budgets

Investigators needing a case trail, not only a model score

High-scale concurrency peak play and payment bursts, not demo traffic

Management wanting to avoid unbounded third-party fraud-platform cost where an in-house + selective-buy mix is defensible

Vision statement (shape we aligned on)

A real-time fraud engine that consumes trusted enterprise events, decides with rules and models under clear SLAs on gaming and payment hot paths, opens explainable cases, and improves continuously without a second shadow data estate.

Stakeholders and concerns

Stakeholder	Concern
Risk / Fraud ops	Catch rate, case quality, tooling
Product / Game	False positives, player friction
Payments	Auth/capture risk, chargebacks
Support	Clear reasons, override path
Platform / EA	Reuse events, avoid duplicate stacks
Finance	Loss vs platform TCO

Phase A outputs a vision stakeholders can argue with. If they only argue about vendor logos, you are still in sales mode, not ADM.

Phase B — Business Architecture how fraud work actually runs

ADM question:What business capabilities, value streams, and processes must change?

For a real-time fraud engine, Business Architecture is the difference between a model demo and an operating model.

Capabilities we mapped

Signal intake- player, session, payment, device, bonus, gameplay events

Detection — rules, velocity, graph/collusion signals, ML scores

Decisioning — allow / challenge / hold / block / step-up (sync on hot paths)

Case management — queue, investigate, evidence, disposition

Feedback — confirmed fraud / false positive back into rules and training

Reporting — loss, funnel, SLA, auditor views

Value streams (simplified)

1. Live play / payment → real-time risk check → decision → continue or friction

2. Post-event review → enrichment → case → action

3. Analyst improvement → pattern found → rule/model change → governed release

Baseline vs target (business)

Baseline: fragmented checks in payment and game services tribal knowledge weak case continuity vendor tools overlapping enterprise data

Target: shared real-time fraud capability clear RACI between risk ops and engineering decision SLAs by channel feedback loop owned

If Phase B is skipped, “fraud AI” projects optimize the wrong verbs.

Phase C — Information Systems Architecture (Data + Applications)

ADM question: What data and applications realize those capabilities?

Data Architecture

Canonical risk events aligned to enterprise event models (game + payment + identity signals)

Feature / profile for real-time attributes (velocity, device reputation, linked accounts)

Decision and reason codes as first-class data (not log line archaeology)

Case and evidence store with retention and access control

Label / outcome data for model and rule learning

ADM forces a hard line: the fraud engine does not get a private parallel universe of “almost the same” player events. Reuse enterprise data products build fraud-specific semantics on top.

Application Architecture

Application Architecture building blocks: Decision API, detection workers, rules and policy, model scoring, case management, admin/simulation, and integration adapters.

Application building block	Responsibility
Fraud Gateway / Decision API	Real-time sync decisions on hot paths
Detection workers / stream jobs	Async scoring and pattern detection
Rules & policy service	Versioned, testable rules
Model scoring service	ML inference with fallback
Case Management app	Investigator UX and workflow
Admin / simulation	Shadow rules, backtests
Integration adapters	Game, payments, wallet, support, notifications

Baseline often shows rules hard-coded inside payment or game services. Target separates decisioning from channel apps so high-scale gaming and payments call one fraud engine instead of each inventing one.

Phase D — Technology Architecture make non-functionals boringly explicit

ADM question: What technology standards and patterns meet the SLAs?

For a real-time fraud engine, NFRs are the architecture:

Latency — hot-path decision budget on game and payment calls

Availability— fail-open vs fail-closed policy by transaction type (a conscious business choice)

Throughput — peak concurrent games and payment bursts

Auditability— every material decision replayable

Security— least privilege on cases; encryption; secrets

Observability — decision metrics, drift, queue age, false-positive rate

Technology patterns that fit this class of engine:

Event backbone already in the enterprise

Low-latency decision service horizontally scaled

Stream/nearline enrichment without blocking the sync path

Datastores fit to access patterns (profiles vs cases vs features)

Isolation of model runtime from rule runtime so one failure mode does not blind both

Phase D is where buy/reuse/build returns vendor case tools might be buy event bus reuse decision service build. ADM does not mandate build. It mandates fit.

Phase E — Opportunities & Solutions packages, not wishlists

ADM question: What solution building blocks and work packages close the gap?

We grouped work so delivery could breathe:

1. Foundation — decision API, reason codes, audit log, adapters (payment + one game path)

2. Detection depth — velocity rules, device/link signals, model score integration

3. Case ops — investigator workflow, evidence attach, disposition codes

4. Intelligence loop— features, backtest harness, governed rule/model release

5. Decommission— retire duplicate checks and overlapping vendor modules

Each package has dependencies and a business outcome. “Big bang fraud rewrite” is not a Phase E output. It is a resignation letter.

Phase F — Migration Planning sequence risk reduction

ADM question:In what order do we move, with what transitional architectures?

Real-time fraud migration is dual-run friendly if you design it

Shadow mode: new engine scores beside old checks compare

Dark launch: decide but do not enforce on selected cohorts

Enforce on lower-blast-radius payment types first

Expand to hotter game paths when false-positive SLAs hold

Keep break-glass override with support/risk RACI

Roadmap is calendar + risk, not only story points. ADM Phase F makes that respectable in front of finance and risk leadership.

Phase G — Implementation Governance architecture is a gate, not a spectator

ADM question: Are delivery teams implementing the architecture we agreed?

Governance checks that mattered for our engine

New channel cannot embed local fraud ifs — must call the Decision API

Reason codes required for player-facing friction

Fail-open/closed matches policy matrix

Hot-path latency budgets are measured, not assumed

PII in cases classified and retained correctly

Model/rule changes go through simulation evidence

Without G, ADM becomes a kickoff deck. With G, ADM becomes how the enterprise stays honest.

Phase H — Architecture Change Management: fraud never sits still

ADM question: How do we respond when the enemy changes tactics?

Fraud is adversarial. Phase H is continuous:

Monitoring abuse pattern shifts and model drift

Intake for new typologies from investigators

Architecture runway for new signals (new payment rail, new game type)

Re-entry to earlier ADM phases when the vision or capability map breaks

If your TOGAF practice has no Phase H operating rhythm, you certified a museum.

Requirements Management — the center that a fraud engine will flood

Every phase dumps requirements into a managed set latency, explainability, retention, jurisdictions, payment-scheme rules, player-experience limits, audit.

ADM’s center is not bureaucracy. It is how you stop a single loud incident from silently rewriting enterprise principles.

What applying ADM changed

What applying ADM changed: without ADM versus with ADM on the real-time fraud engine.

Without ADM	With ADM on the real-time fraud engine
Vendor demo drives scope	Vision and capabilities drive scope
Engineers argue tools first	Business architecture names the work
Shadow data copies appear	Data architecture reuses enterprise events
Hot path latency is a surprise	NFRs are Phase D contracts
Big-bang cutover fantasy	Migration with shadow and dark launch
Architecture finishes at design review	Governance and change management continue

TOGAF did not give us the fraud engine. ADM gave us a way to decide and sequence one for high-scale gaming and payments.

How to steal this for your next Architecture Board

1. Pick a real problem with enemies, regulators, or revenue on the line.

2. Walk A→H as questions, not as mandatory 40-deliverable cosplay.

3. Write principles in Preliminary before tool shortlists.

4. Force Business Architecture before ML heroics.

5. Make fail-open/closed latency, and explainability explicit in Technology Architecture.

6. Package E/F so risk shrinks every release.

7. Keep G/H alive or admit you only did waterfall with extra shapes.

Whenever a complex business problem lands on your desk, try following ADM. It will not hand you magic answers. It will hand you a clear picture.

Wrapping-Up

TOGAF looks heavy when you study it as a framework. It becomes simple when you apply ADM to something that can hurt the business.

For us, that something was a real-time fraud engine for high-scale gaming and payments. Stakeholders, capabilities, data, applications, technology, migration, governance, and change under adversarial load.

Theory becomes useful the day you stop redrawing the ADM crop circle and start answering its questions against a working method.

September 12, 2026

REST, gRPC, GraphQL, WebSocket — When to Choose Which

What we keep missing in the Architecture Review Board — and the drawbacks of each pattern

When a new requirement lands, we open the Architecture Review Board (ARB).

The room fills quickly. Mid-level engineers come prepared — and passionate. Someone says: “We’ll do gRPC.” Someone else: “GraphQL is better for the UI.” Another: “Just expose a REST API — everyone knows it.”Occasionally WebSockets enter the chat because “we need real-time.”

I understand the concern. Everyone is trying to move fast and pick a modern, credible tool.

But sometimes we miss the fundamentals between all of them.

gRPC, GraphQL, REST, and WebSocket are not competing logos. They are different communication patterns. They answer different questions about how long the conversation lasts, who is calling, how much of the data the client needs, and what fails when the network gets ugly.

In this article I explain when to choose which communication pattern, and — just as important — what the drawbacks of each are. The examples come from high-scale gaming and payments platforms we built: matchmaking, live tables, real-time query APIs, and service-to-service paths behind the client.

Same ARB energy. Clearer criteria.

What the ARB should ask before naming a protocol

Before anyone says “gRPC” or “GraphQL,” force these questions:

1. Is this a short request/response, or a living session?

2. Is the caller a browser/app, a partner, or an internal service we control?

3. Does the client need a fixed contract, a flexible read shape, or a stream of events?

4. Are we optimizing for universality and debuggability, binary efficiency, or push latency?

5. Who owns versioning when the contract changes?

If you cannot answer those, you are not choosing a pattern. You are choosing a buzzword.

REST — when to choose it

Choose REST when the interaction is “ask and get an answer”: short-lived, resource- or command-oriented, and best served by ordinary HTTP (methods, status codes, gateways, caches).

Matchmaking was a scalable REST service. The client called it first. The service read live tables/seats from cache, applied rules, and returned game table info (later including a sticky cookie). Only then did the client know where to play.

The Dynamic Real-Time Query Engine exposed REST APIs so CRM, ML, and targeting could send a behavioral query and get a decision. Request/response. Wide consumer set. Spring Boot + HTTP was the interoperable door.

Why ARB likes REST (for good reasons)

Every platform can call it

API gateways already know how to auth, rate-limit, and route it

Easy to debug (`curl`, logs, status codes)

Natural for onboarding, config, “place me,” “get segment,” partner integrations

Drawbacks / backdrops

Chatty UIs — one screen may need many round trips

Over-fetching / under-fetching — one DTO rarely fits every client

Poor fit as the primary game loop — polling REST for table state is a smell

Versioning sprawl — `/v1` `/v2` and bloated payloads if governance is weak.

ARB line: If the conversation ends when the response returns, REST is the default until proven otherwise.

WebSocket — when to choose it

Choose WebSocket when you need a persistent, bidirectional channel: server push, client push, session as long as the user is inside an experience.

Where it fit for us

Gameplay was never REST polls. Early on, clients held a persistent socket for the life of the session — input in, broadcast out.

Later we moved to WebSockets behind an API gateway (auth, security, rate limits, routing).

Flow:

1. REST matchmaking → table info + sticky cookie

2. WebSocket through the gateway → live game path

3. Stay connected for the session; server fans out state

Historically we also separated lobby vs game connections so browsing spikes did not punish a live table.

Why ARB likes WebSocket

True real-time without fake polling

Efficient for many small messages after handshake

Matches how games, live ops, and collaborative UIs actually work

Drawbacks / backdrops

Operational hardness — sticky sessions, reconnect storms, heartbeats, backpressure

Gateway and LB behavior become architecture — not an afterthought

Horizontal scale is non-trivial — affinity, failover, “who owns this gameId?”

Abuse risk — open sockets are a DoS surface if rate limits and auth are weak

Wrong tool for one-shot CRUD — login and “get config” do not need a socket

ARB line: Use REST (or similar) to enter the room. Use WebSocket to live in the room.

gRPC — when to choose it

Choose gRPC when callers are services inside your trust boundary, you want a strict contract (Protobuf), and you care about efficiency, deadlines, and codegen. Where it fits in stacks like ours

Client-facing traffic stayed REST + WebSocket. gRPC earns its keep service-to-service:

High-QPS internal lookups (profile, features, decision helpers)

Strong typing across languages

Unary or streaming RPCs without inventing a private framing protocol

A fraud Decision API or internal RTQE neighbor might speak gRPC internally while broader consumers still see REST.

Why ARB likes gRPC

Compact binary payloads; strong performance story

Contract-first with breaking-change discipline

Deadlines, status codes, streaming built in

Excellent for polyglot microservices you own

Drawbacks / backdrops

Browsers are awkward — need grpc-web or a proxy; not “just fetch”

Ops complexity — HTTP/2 load balancing, observability, and client libraries must be mature

Less human-debuggable than JSON REST in a pinch

Overkill for simple public or partner APIs

False comfort — a `.proto` does not replace product thinking about failure modes

ARB line: gRPC for internal contracts. Do not force it to the client because it feels advanced.

GraphQL — when to choose it

Choose GraphQL when many clients need different shapes of the same domain, and REST over/under-fetching is slowing product teams — and you are willing to govern a schema.

Where it fits

BFF / app / admin / CRM consoles: screens that would otherwise need five REST calls or one monstrous DTO.

Where I push back hard

Hot game loops — use WebSocket state sync, not GraphQL as the table protocol

Simple commands — REST is clearer

Blind “GraphQL everywhere” — schema sprawl is an enterprise debt

Why ARB likes GraphQL

Clients ask for exactly the fields they need

One endpoint can serve many UI variants

Strong story for mobile and parallel frontends

Drawbacks / backdrops

N+1 and resolver cost — easy to create accidental database storms

Caching is harder than REST resource URLs

Authz must be field-aware — coarse gateway auth is not enough

Schema governance — without owners, GraphQL becomes a junk drawer

Subscriptions ≠ free real-time architecture — still need backplane thinking

ARB line: Choose GraphQL for read-shape flexibility. Do not choose it to avoid designing APIs.

Side-by-side: pattern vs backdrop

Pattern	Choose when	Main drawbacks
REST	Short request/response; broad clients; gateways	Chatty UIs; over/under-fetch; weak as live game pipe
WebSocket	Long-lived bidirectional session; server push	Sticky/reconnect complexity; harder to scale; easy to misuse for CRUD
gRPC	Internal service RPC; strict contracts; efficiency	Browser friction; ops maturity required; overkill for public CRUD
GraphQL	Many clients, many read shapes	N+1; cache/authz hardness; schema sprawl

How we composed them (what “good” looked like)

Conversation	Pattern
Matchmaking / “where do I sit?”	REST
Live gameplay / presence	WebSocket
CRM / ML segment query	REST (+ JSON body)
Service-to-service, high QPS, strict	gRPC (internal)
Diverse admin / app reads	GraphQL (when UI diversity demands it)
Durable async side effects (e.g. money path)	Message broker — different layer, not a fifth “API style”

What I say in the ARB when the suggestions fly

When someone says “we’ll do gRPC / GraphQL / REST,” I translate:

REST — “We need a door everyone can knock on.”

WebSocket — “We need a room that stays open and pushes.”

gRPC — “Two services we own need a tight, fast contract.”

GraphQL — “Many UIs need many shapes of one graph — and we will govern the schema.”

If the sentence is only “it’s modern,” that is not an architecture decision.

Wrapping-Up

In the ARB, mid-level energy is valuable. Protocol fashion is not.

Sometimes we miss the funda: REST, gRPC, GraphQL, and WebSocket solve different communication problems, and each brings drawbacks you must budget for — chattiness, connection ops, browser proxies, schema and resolver risk.

When a new requirement opens the board, don’t start with the acronym. Start with the conversation type. Then choose the pattern. Then name the backdrops out loud so nobody is surprised in production.

Enter with REST when you need a door.

Stay with WebSocket when you need a room.

Speak gRPC when services need a tight contract.

Offer GraphQL when many UIs need many shapes — and you will own the schema.

September 11, 2026