Cap’n Proto
by Kenton Varda, Cloudflare
Zero-copy RPC protocol with promise pipelining that eliminates serialization overhead and network latency in data-intensive systems
Core Problem Solved
Traditional RPC protocols (JSON-RPC, HTTP, Protobuf) require expensive serialization/deserialization cycles that consume CPU and create network latency bottlenecks. Cap’n Proto’s wire format is identical to in-memory representation, allowing data to be read directly without transformation.
The Zero-Copy Principle
Traditional Approach (JSON-RPC, Protobuf)
In-Memory Data → Encode to Wire Format → Send → Receive → Decode to In-Memory Data
Each step requires CPU-intensive transformation and rebuilding of object graphs. O(n) complexity where n is message size.
Cap’n Proto Approach
In-Memory Data ← → Wire Format (identical layout)
Data can be read directly from the wire without transformation. O(1) complexity regardless of message size.
Performance: Concrete Benchmarks
For a message with single 1024-byte string field:
| Operation | Protobuf | Cap’n Proto | Overhead |
|---|---|---|---|
| Initialize Data | 34 ns | 408 ns | +1100% |
| Copy String Payload | 167 ns | 80 ns | -52% |
| Encode to Wire | 351 ns | 53 ns | -85% |
| Decode from Wire | 491 ns | 78 ns | -84% |
| TOTAL | 1043 ns | 619 ns | -41% |
Cap’n Proto’s encode/decode steps are nearly negligible (53ns + 78ns) because wire format matches in-memory layout exactly.
Implications
- CPU savings: 40%+ on serialization overhead
- Memory efficiency: Lazy loading via OS page faults
- Bandwidth: Packed encoding (RLE) compresses zero-bytes without CPU cost
Memory Management: Lazy Loading
Cap’n Proto delegates memory management to OS through page faults and lazy loading:
- Only accessed data is loaded into physical RAM
- Can handle datasets larger than available memory
- Instant startup time (no pre-allocation)
JSON-RPC must allocate memory upfront and rebuild entire object graphs—scales linearly with message size.
Promise Pipelining: Eliminating Network Latency
The biggest innovation: “Level 3 RPC” or “Time Travel” RPC that converts network latency into local memory throughput.
Example: Chained Operations
Traditional RPC (3 sequential round-trips):
client.db.getUser(id) // Wait 50ms
client.profile(user) // Wait 50ms
client.picture(profile) // Wait 50ms
// Total: 150ms minimum
Cap’n Proto Promise Pipelining (1 round-trip):
// Client sends all 3 operations as batch
// Server executes: getUser → passes to getProfile → passes to getPicture
// Returns only final result
// Total: ~50ms
How it works:
- Client sends three operations as batch
- Server receives and executes getUser
- Server passes result directly to getProfile (no serialization, no network)
- Server passes that result to getPicture
- Server returns only final result to client
- Client receives complete answer in one round-trip
Result: Converts expensive network latency problem into fast, predictable local memory throughput problem.
Design Philosophy
Cap’n Proto prioritizes:
- Hardware efficiency (CPU, memory, network)
- Schema flexibility (validation pushed to application level)
- Operator simplicity (avoid operational pain of strict validation)
vs. JSON-RPC which prioritizes:
- Human readability (text-based interchange)
- Simplicity (easy to debug, text parsing)
- Acceptance of serialization overhead
Bandwidth Optimization: Packed Encoding
While 64-bit alignment can create larger messages, Packed Encoding (RLE) compresses zero-bytes:
64-bit word all zeros → Tag 0x00 (1 byte)
64-bit word all ones → Tag 0xFF + 8 bytes
64-bit word partial fill → Tag + only non-zero bytes
Result: Compression competitive with Protobuf while maintaining zero-copy read capability.
Trade-offs and Limitations
When Cap’n Proto Shines
- Systems with CPU bound during serialization
- High-frequency, low-latency agent interactions
- Large message volumes or data-intensive workloads
- Chained RPC calls (promise pipelining benefit)
When JSON-RPC Better
- Human debugging requirements (text-based)
- Schema flexibility without types needed
- Serialization is not a bottleneck
- Broader ecosystem/standardization needed
Implementation Complexity
- More complex to implement than JSON
- Requires proper language bindings
- Schema evolution requires more careful planning
- Not as human-readable as text formats
Schema Evolution Philosophy
Cap’n Proto’s approach to schema evolution is deliberately cautious:
- Application-level validation (not protocol-level)
- Allows schemas to evolve without operational complexity
- Informed by experiences at Google where changing optional/mandatory caused failures
Use Cases
- High-frequency trading systems (microsecond latency requirements)
- Real-time data streaming (large message volumes)
- Distributed databases (internal RPC protocols)
- Microservices with strict latency requirements (sub-millisecond SLAs)
- IoT/embedded systems (memory efficiency)
vs. Protocol Alternatives
vs. Protocol Buffers (Protobuf)
- Cap’n Proto: Faster encode/decode, zero-copy reads
- Protobuf: More widely adopted, larger ecosystem
vs. JSON
- Cap’n Proto: 40%+ faster, zero-copy, memory efficient
- JSON: Human readable, broader tool support
vs. MessagePack
- Cap’n Proto: Promise pipelining (network latency elimination)
- MessagePack: Simpler, smaller library
vs. MCP (JSON-RPC)
- Cap’n Proto: Higher performance for numeric/data-heavy workloads
- MCP: Broader standardization for AI agent tool integration
Language Bindings
Official support:
- C++, Rust, Java, Python, JavaScript, Go, C#
Used internally at:
- Google (in some infrastructure)
- Cloudflare (DNS/network infrastructure)
- Various trading firms and data-intensive systems
When Replacing MCP with Cap’n Proto Makes Sense
Scenario: High-frequency agent decision-making with numeric-heavy operations
Example:
- 1000s of agents making decisions per second
- Each decision requires computing across large datasets
- Current MCP JSON-RPC overhead = bottleneck
Benefit: 40%+ CPU reduction + promise pipelining for chained operations
Cost: Loss of MCP ecosystem standardization, custom implementation required
Strategic Position
Cap’n Proto is a specialized tool for performance-critical systems. It won’t replace MCP as the standard AI agent protocol, but for specific use cases where latency or CPU efficiency is paramount, it provides superior architecture.
The principle behind Cap’n Proto is worth broader adoption: Memory is the new disk, CPU is precious—optimize for hardware efficiency.
Resources
Related
- LeanMCP – MCP deployment platform (uses JSON-RPC)
- Model Context Protocol – Standard AI agent protocol (uses JSON-RPC)
- Zapier MCP – Pre-built MCP integrations
- Google Vertex AI Agent Builder – Managed agent platform
- Protobuf – Traditional serialization format (for comparison)