Why ZAP?

ZAP Protocol was designed to solve real problems in building high-performance distributed systems. This page explains the motivation behind ZAP and how it compares to alternatives.

The Problem

Modern distributed systems face several challenges:

1. Serialization Overhead: JSON and Protobuf require parsing, adding latency
2. Transport Limitations: Most frameworks lock you into a single transport
3. Consensus Complexity: Adding BFT consensus is typically a separate integration
4. Code Generation Friction: Poor tooling leads to manual boilerplate

How ZAP Solves These

Zero-Copy Serialization

Cap'n Proto's wire format is directly usable in memory. There's no parsing step - data is accessed in-place from the buffer.

Traditional RPC:
  Wire -> Parse -> Memory Object -> Use

ZAP:
  Wire -> Use (directly)

Benchmark comparison (10,000 messages):

Transport Flexibility

ZAP abstracts the transport layer, letting you choose based on your needs:

Switching transports requires no code changes:

// TCP (default)
client, _ := zap.Dial("tcp://localhost:9000")

// Unix socket
client, _ := zap.Dial("unix:///var/run/zap.sock")

// WebSocket
client, _ := zap.Dial("ws://localhost:9000/rpc")

Integrated Consensus

ZAP includes optional Byzantine fault-tolerant consensus. Enable it with a single configuration change:

server := zap.NewServer(
    zap.WithConsensus(zap.BFT{
        Nodes: []string{"node1:9000", "node2:9000", "node3:9000"},
        Threshold: 2,
    }),
)

No separate Raft/Paxos integration required.

First-Class Code Generation

ZAP's code generator produces idiomatic, type-safe code:

zap generate service.capnp --lang=go

Generated code includes:

• Type-safe client stubs
• Server interface definitions
• Streaming helpers
• Error types

Comparison with Alternatives

vs gRPC

Choose ZAP when: You need maximum performance, transport flexibility, or built-in consensus.

Choose gRPC when: You need broad ecosystem support or HTTP/2 features.

vs Cap'n Proto RPC

ZAP builds on Cap'n Proto's serialization but adds the infrastructure for production systems.

vs JSON-RPC

Choose ZAP when: You need performance and type safety.

Choose JSON-RPC when: You need maximum simplicity and human-readable messages.

When to Use ZAP

ZAP is ideal for:

• High-throughput services: Financial systems, game backends, real-time analytics
• Low-latency requirements: Trading systems, live collaboration, IoT
• Distributed consensus: Blockchain nodes, distributed databases, leader election
• Polyglot environments: Services in Go, Rust, and TypeScript communicating seamlessly

When Not to Use ZAP

Consider alternatives when:

• Simple REST APIs: Standard HTTP APIs may be simpler
• Browser-only clients: If you only need browser clients, consider GraphQL
• Existing Protobuf schemas: Migration cost may outweigh benefits

Performance Benchmarks

Tested on AWS c5.xlarge (4 vCPU, 8GB RAM):

Throughput (requests/second)

Latency (p99, microseconds)

Summary

ZAP Protocol provides:

1. Maximum performance through zero-copy serialization
2. Transport flexibility for any deployment scenario
3. Built-in consensus for distributed systems
4. Excellent developer experience with code generation

If you're building high-performance distributed systems and need more than what traditional RPC frameworks offer, ZAP is worth evaluating.