Transaction coordinator

As explained in Think Distributed Systems

A component that receives requests, assigns them an order, and distributes the ordered requests to other components.

A transaction coordinator (TC) receives requests from clients or proposers, assigns them an order or shared decision, and distributes that order or decision to participating components. It turns independently arriving requests into coordinated behavior. section 2.2 section 6.3.1

A useful mental model is a numbered dispatcher. The coordinator tags requests in arrival order, while recipients track the latest applied tag and wait for missing requests. In distributed transactions, it instead gathers participants’ votes and announces one shared commit-or-abort decision. section 2.2 section 6.3.1

In two-phase commit, the coordinator proceeds as follows:

• Prepare: persistently records Prepare and asks every resource manager whether it can commit. section 6.3.1
• Decide: commits only after every resource manager votes to commit; otherwise, an abort vote or timeout selects abort. section 6.3.1
• Distribute: persistently records the decision and sends Commit or Abort to all participating resource managers. section 6.3.1

Ordering conflicting requests

Two proposers issue +2 and ×2. Even if the network delivers ×2 first, the coordinator can tag it 0 and +2 1. Acceptors then apply the requests in tag order rather than network-delivery order. The same coordination role has a sharper failure cost in two-phase commit: if the coordinator fails after participants vote to commit, those participants may remain blocked until it recovers. section 2.2 section 6.3.2

Figure 2.12 Proposers, acceptors, and a coordinator

Shows proposers, the coordinator, and acceptors as a concrete request-ordering system. section 2.2

How Think Distributed Systems covers it

How deep it goes

Defines ordering and two-phase commit operationally, then distinguishes safety from liveness under coordinator and participant failures.

Examples

Uses numbered +2 and ×2 requests, Prepare and Commit phases, persistent logs, timeouts, and coordinator-failure scenarios.

What it assumes

Assumes distributed components, communication failures, resource managers, and local transactions while defining the coordinator’s role explicitly.

What you can do after

Evaluate how coordination establishes order, reaches atomic decisions, and can block when the coordinator fails.

How it connects

Connects to race conditions, distributed transactions, atomic commit, two-phase commit, resource managers, safety, and liveness.

liveBookmanning.com

Read Think Distributed Systems on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Apache Kafka in ActionA transaction coordinator is the Kafka broker component that coordinates a transaction and writes markers recording its commit or abort outcome.

Compare how 2 books explain transaction coordinator →

Related concepts

• Kafka brokerkind of · A Kafka broker is a server process in an Apache Kafka cluster that stores records and handles producer, consumer, and other client requests.
• distributed transactionused by · A distributed transaction is a unit of work whose operations span multiple resources or systems and whose outcome is coordinated across them.
• transactional producerused by · A transactional producer is a Kafka producer mode that publishes records to multiple topics as one atomic transaction, committing all records together or none of them.
• race conditionaddresses · A race condition is a concurrency defect in which program behavior or results depend on the relative timing or ordering of interacting operations.

This explainer was generated by Manning's knowledge graph from the text of Think Distributed Systems. The section links point to the parts of the book it draws on.