Part 12 · Modern Frontier

The previous twelve parts are, deliberately, mostly timeless: caching, replication, sharding, consensus, idempotency, and the six-step design framework will read the same in 2035 as they do today. This final part is the opposite — it’s a snapshot. It’s about the ingredients that have moved from research papers and hyperscaler-only infrastructure into the toolkit of an ordinary team in the mid-2020s: a feature backed by a large language model, code that runs on a CDN’s edge instead of in your datacenter, and a data layer that’s quietly merging transactional, analytical, and vector workloads. These are frontier topics not because they’re untested, but because the patterns around them are still being figured out in public, and the trade-offs are sharper and less settled than the ones in Part 0.

Why a dated chapter in a first-principles book

Everywhere else this book avoids version numbers and product names so it won’t rot. Here we embrace them, because the whole point is what changed recently and what it costs you. Read this part as a photograph labelled “as of 2025.” The principles underneath — latency budgets, statelessness, the storage hierarchy, trade-off thinking — are the durable parts; the specific tools are the parts that will date.

What’s actually new

Strip away the hype and three genuinely new constraints have entered mainstream system design:

1. NON-DETERMINISM AS A FEATURE   A core component (the LLM) is probabilistic,
                                  slow, expensive per call, and occasionally wrong.
                                  Design must tolerate and bound that.

2. COMPUTE THAT MOVES TO THE USER Functions run at hundreds of edge POPs and spin
                                  up per-request. Cheap to start, but stateless and
                                  far from your database.

3. ONE DATASET, THREE SHAPES      The same data wants a row store (OLTP), a column
                                  store (OLAP), and a vector index (semantic search)
                                  — and the stacks are converging to serve all three.

None of these repeals the fundamentals. An LLM call is still a slow network dependency you must put a timeout and retry around. An edge function is just an extreme case of the statelessness you already learned to value. A vector database is an index with an unusual distance function. The frontier is the fundamentals, recombined under new cost curves.

The roadmap: three frontier pages

This part is short and pointed. Each page takes one shift, frames it as of 2025, and runs it through the same lens as everything before it.

Page	The shift it covers
Building With LLMs	RAG and vector retrieval, the new latency/cost/non-determinism budget, streaming UX, guardrails and evals
Edge & Serverless	CDN workers and serverless functions, cold starts, the stateless constraint, when the edge wins and when data-locality bites
The Data-Intensive Frontier	Streaming (Kafka/Flink), the lakehouse, change data capture, vector ANN indexes (HNSW/IVF), and OLTP/OLAP/vector convergence

Read them in order if you like, but they stand alone. Building With LLMs is the one most teams meet first, because a product manager asked for a chatbot. Edge & Serverless is where its latency and cost get paid. The Data-Intensive Frontier is the substrate underneath both — the pipelines and indexes that feed the model and serve the analytics.

The thread, one more time

What does this buy us, and what does it cost? It has carried us through every part of this book, and it matters most here, because frontier tools are sold on what they buy and quiet about what they cost. An LLM buys you a feature that would have been impossible to hand-code — and costs you determinism, latency measured in seconds, a per-token bill, and a brand-new abuse surface. The edge buys you single-digit-millisecond proximity to users — and costs you closeness to your data. A converged data platform buys you one system instead of three — and costs you the specialization each of those three was good at. The job, as ever, is to see both columns clearly before you sign up for either. The rest of this part is three careful accountings of exactly that.