Bondy Connect
Skip to content

Why Bondy ​

Distributed applications are the default, not the exception ​

Microservices applications are the most common and complex type of distributed application being built today. As Christopher Meiklejohn noted at Strangeloop 2022, "We are all now building distributed systems!"[1] Whether you're developing microservices, integrating multiple customer touchpoints, or connecting IoT devices, you're in the business of distributed computing.

Today's applications need real-time, networked connections between people, processes, data, and devices[2]. Building those connections typically means assembling a large number of infrastructure components, protocols, APIs, and client libraries[3].

The root cause: protocol fragmentation ​

A typical distributed application assembles:

  • HTTP/REST or gRPC for synchronous request-response communication
  • A message broker (RabbitMQ, Kafka) for asynchronous event distribution
  • A service mesh for service discovery, load balancing, and traffic management
  • An API gateway to expose services to external clients
  • A separate authentication and authorization service
  • WebSockets where HTTP's request-response model isn't enough

Each component brings its own protocol, client libraries, operational model, and failure modes.

Fred Brooks distinguishes essential complexity — inherent to the problem — from accidental complexity, which engineers create and can remove[4]. The complexity of integrating six separately-designed protocols and infrastructure components to cover one application's messaging needs falls into the second category: it comes from the tools chosen, not from the problem itself.

Most of these protocols were designed as vertical solutions for one use case — HTTP for document retrieval, message queues for asynchronous job processing, gRPC for efficient service-to-service calls — and each carries assumptions from three-tier, monolithic applications: a client-server model where mobile apps, IoT devices, and browser tabs are not first-class participants, and where a peer-to-peer interaction has to be built as a workaround rather than expressed directly.

What this costs ​

  • Slower delivery, as developers navigate multiple technologies and integration patterns.
  • More to maintain, since each component has its own upgrade path and failure modes.
  • More to operate, running and monitoring several infrastructure components instead of one.
  • More points of failure, one per component in the chain.

What a single protocol buys back ​

WAMP unifies RPC and Pub/Sub in one protocol with a peer-to-peer programming model, transport-agnostic and with multiple serialization formats, plus built-in multi-tenancy through realms — see What is WAMP. Because every kind of client uses the same protocol and the same semantics over the same connection, a browser can expose a procedure for a server to call, not only call procedures itself: the architecture can be genuinely peer-to-peer rather than client-server with an extra channel bolted on.

Bondy is a WAMP router that additionally:

  • Scales horizontally with a masterless distributed architecture — see Architecture.
  • Maintains availability under partition through active anti-entropy — see Clustering.
  • Provides authentication and fine-grained RBAC built in.
  • Integrates with existing systems through an HTTP API Gateway and message broker bridges.
  • Runs anywhere, from edge devices to cloud environments, with no external dependencies.

AI agent communication ​

The same properties that make WAMP suit distributed applications generally — RPC and Pub/Sub unified, peer-to-peer by default, authentication/authorization/multi-tenancy built in — apply directly to AI agent systems, where an agent typically needs to both expose capabilities and consume them, and needs event coordination alongside function calling. See WAMP for agent-to-agent communication for the detailed case, including the comparison against agent-specific protocols such as MCP.

What replacing the stack looks like ​

Instead of:

Web App → API Gateway → gRPC → Service A → Kafka → Service B
                ↓                          ↓
          Load Balancer            Message Queue
                ↓                          ↓
          Service Mesh             More Services

Every component connects directly to Bondy:

Web App → Bondy ← Services

Every component uses the same protocol and gets RPC, Pub/Sub, authentication, authorization, service discovery, and load balancing from it, without an adapter or translation layer between components that speak different protocols.

See also ​


  1. Christopher Meiklejohn, Strangeloop 2022 Resilient Microservices without the Chaos ↩︎

  2. The Internet of Everything ↩︎

  3. Stephen O'Grady, The Developer Experience Gap ↩︎

  4. In No Silver Bullet — Essence and Accident in Software Engineering, Fred Brooks distinguishes between two different types of complexity: accidental complexity and essential complexity. Essential complexity is caused by the problem to be solved, and nothing can remove it. Accidental complexity relates to problems which engineers create and can fix. ↩︎