Build1 publisher2 min readPublished
Ian Cooper's ABCs define what every event-driven endpoint has to publish
Ian Cooper says event-driven orgs of up to about five teams can manage async APIs on shared knowledge of each other's services. His model for doing it at scale begins with the address, binding and contract each endpoint has to describe to its consumers.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Cooper works on Brighter, an open-source messaging framework for .NET developers, and gave the talk on managing asynchronous APIs that InfoQ published.
- The address, binding and contract shorthand comes from Clemens Vasters, who created it for the WCF .NET framework about 15 years ago.
- In Cooper's model a channel is a logical pipe, which Kafka implements as a topic and RabbitMQ as a routing key.
- A message body also needs a declared format, whether JSON, plain text, Avro or Protobuf, before a consumer can process it.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A team that renames or drops a header can change what a filtering consumer processes, so header changes need the same review as payload schema changes.
- decision Platform teams have to set a rule on bindings per channel, and Cooper's Kafka-plus-SNS warning argues for one binding per channel as the default.
- decision An org nearing five teams has to choose when to start writing down each endpoint's address, binding and contract instead of relying on teams knowing each other.
Cooper's worked example is a restaurant management service that publishes a message when restaurant hours change [5]. A consumer may filter on a country-code header to decide which of those messages to handle [6]. "You need to understand what headers I'm going to publish," he said [6]. I think the header is the part of an event contract most likely to change without notice, because it looks like transport plumbing to the team that sets it. The filter that reads it sits in a different team's service [6].
The split between channel, binding and contract is the strongest part of the model. In Cooper's breakdown, the binding carries the protocol, the server location, transports and encoding [9][11]. The contract carries the headers and the payload [11]. No broker name appears in the contract [11]. Cooper noted that a channel can in principle have more than one binding, for example Kafka and SNS at the same time [9]. "It would be very confusing for most people," he said [9]. I would allow one binding per channel and make any second binding something a team has to justify.
On the slide, the model got crowded. "This diagram, as you can see, has now got very busy," Cooper said [15]. His definition of the thing being described is short: "Endpoints are places where messages are sent or received" [4]. So is his rule for what to publish. "When you think about endpoints, what you need to describe to other people to use them are the ABCs," he said [12].
Cooper framed the talk around "the somewhat thorny topic" of managing "all the APIs that you're now generating" after a move to event-driven architecture [1]. He promised three pillars for doing it [3]. His case for small orgs rests on teams knowing each other. "Typically, the surface area is not big enough that you don't know about each other's services," he said [13]. The published transcript ends mid-sentence in that small-org passage, before he names any pillar [14]. It does not show what he recommends on versioning or discovery once an org grows past about five teams [14].
What to watch
- The rest of Cooper's talk, where he names his three pillars and says what changes for orgs past about five teams, including whether versioning and discoverability are among them.
- Whether Brighter exposes channel, binding and contract descriptions that consuming teams can read without asking the publishing team.