Adjacent Topics

The starting point for MCP: what the protocol is, why it exists, and the mental model for tools, resources, and prompts. The architecture overview on this site is the fastest path to understanding why MCP is structurally different from ad-hoc REST.

The full protocol specification. The transport and capability-negotiation sections in particular show how MCP enforces an explicit contract between client and server — directly relevant to the thesis that service shape determines agent composability.

The announcement that framed MCP as open infrastructure rather than a proprietary API. The section on why it was open-sourced explains the ecosystem bet: interoperability beats lock-in when the goal is an agent-native tool ecosystem.

Implementation-level reference for tool calling in Claude. Useful as a concrete example of what an MCP-compatible service contract looks like from the agent side: JSON Schema tool definitions, structured inputs and outputs, no out-of-band state.

Fowler's canonical definition of the DTO pattern. Short and precise. Worth reading alongside the DTOs-and-mappers post: the pattern predates microservices but its purpose maps directly to the service-boundary question — what crosses the wire defines the contract.

The vocabulary for describing and validating JSON documents. When a service's external surface is JSON, JSON Schema is the contract. The draft evolution (Draft-07 → 2019-09 → 2020-12) gives concrete intuition for schema-evolution tradeoffs and what "backward compatible" means in practice.

Google's language-neutral serialization format. The field-number-based schema evolution model is worth studying even if you never ship a `.proto` file: it's a clean, battle-tested solution to the backward-compatibility problem that JSON Schema sidesteps by allowing arbitrary structure.

An OpenAPI-equivalent specification for event-driven APIs — message queues, pub/sub, WebSockets. Relevant for any service that exposes an event stream rather than a request/response surface, and directly adjacent to the observability checkpoint pattern.

Kyle Kingsbury's analyses of real databases under network partitions. Indispensable reading alongside the CAP-theorem post: it turns the theorem from an abstract trilemma into concrete failure modes that show up in production systems. The analyses also model good observability — every claim is backed by a reproducible test.

A rigorous argument that the CP/AP binary is too coarse to reason about real systems. Directly extends the CAP post: after you understand the theorem, this article explains why the labels are still insufficient — and what more precise vocabulary to reach for instead.

Amazon CTO's blog, where the "eventually consistent" framing that underpins modern distributed-systems thinking was articulated. Reading Vogels alongside Kleppmann gives both the practitioner perspective and the theorist's pushback.

Reference for Redis data structures and persistence models. Relevant alongside the hash-function posts: Redis exposes hashing, probabilistic structures (Bloom filters, HyperLogLog), and sorted sets as first-class primitives — a concrete survey of memory-shape choices a service can make.

The CNCF observability framework: traces, metrics, and logs under one specification. The correlation model — linking a trace ID across logs and spans — is the practical implementation of the structured-log principle: every event should carry enough context to be replayed or queried independently, without reference to application state.

Treat logs as event streams. Concise and foundational: the insight that a service should not know where its log output goes is the same insight that drives structured JSONL checkpoints — the service emits events, infrastructure decides what to do with them.

Charity Majors and the Honeycomb team's work on high-cardinality observability. Their argument — that wide events with rich fields are qualitatively different from aggregated metrics — applies directly to the checkpoint pattern: agents need queryable event streams, not pre-aggregated dashboards.

The format that borg-net's observability checkpoints use: one JSON object per line, newline-delimited, appendable, greppable. The spec is short. The constraints — no nesting across lines, no top-level arrays — are the feature: they make JSONL files safe to append concurrently and trivial to process with standard tools.

The JDK Enhancement Proposals index. The best way to trace the feature evolution covered in the java-evolution post: each JEP has a motivation section that names the service-design problem the language change was solving. Records and sealed classes, for instance, are explicitly framed as domain-modelling tools.

The official OpenJDK team blog: in-depth feature explanations, performance work, and design rationale. Useful companion to the Java 8→21 evolution post for readers who want to go deeper on any specific release, particularly Project Loom (virtual threads) and Project Valhalla (value types).

The reference site most Java practitioners reach for. Particularly strong on Spring, JPA, and collections. When a borg-net post explains a concept, Baeldung is usually the right next stop for implementation-level depth and annotated code examples.