Apache Kafka · Arazzo Workflow

Apache Kafka Review Cluster and Topic Capacity

Version 1.0.0

Walk a cluster from brokers to topics to the partition and replica layout of one topic.

1 workflow 4 source APIs 1 provider
View Spec View on GitHub Distributed SystemsEvent StreamingMessagingOpen-SourcePub-SubArazzoWorkflows

Provider

apache-kafka

Workflows

review-topic-capacity
Audit a topic's partition and replica layout against the cluster's brokers.
Reads cluster, brokers, topic inventory, and per-partition replica placement for a single topic so capacity and durability can be assessed together.
5 steps inputs: clusterId, topicName outputs: brokers, partitions, partitionsCount, replicationFactor, topics
1
readCluster
Read the cluster to confirm it exists and to capture the controller reference that anchors the rest of the audit.
2
listBrokers
List the brokers in the cluster. The broker count is the hard ceiling on any topic's replication factor and the baseline for judging replica spread.
3
listTopics
Inventory the cluster's topics, giving the audit the full picture of what is deployed before narrowing to one topic.
4
readTopic
Read the target topic's declared partition count and replication factor, which is what the audit compares against the broker list.
5
readPartitions
Read the per-partition detail, exposing the leader and replica set for each partition. This is where leader skew and under-replication become visible.

Source API Descriptions

Arazzo Workflow Specification

Raw ↑
arazzo: 1.0.1
info:
  title: Apache Kafka Review Cluster and Topic Capacity
  summary: Walk a cluster from brokers to topics to the partition and replica layout of one topic.
  description: >-
    A read-only audit that answers whether a topic's partitioning and
    replication actually match the cluster it runs on. It reads the cluster and
    its brokers to establish how many are available, inventories the topics,
    then drills into one topic and its partitions to see the leader and replica
    placement per partition. Reviewing replica placement against the broker list
    is how under-replicated partitions and leader skew get caught before a
    broker loss turns them into an outage. Every step spells out its request
    inline so the flow can be read and executed without opening the underlying
    OpenAPI description.
  version: 1.0.0
sourceDescriptions:
- name: brokerApi
  url: ../openapi/apache-kafka-broker-api-openapi.yml
  type: openapi
- name: clusterApi
  url: ../openapi/apache-kafka-cluster-api-openapi.yml
  type: openapi
- name: partitionApi
  url: ../openapi/apache-kafka-partition-api-openapi.yml
  type: openapi
- name: topicApi
  url: ../openapi/apache-kafka-topic-api-openapi.yml
  type: openapi
workflows:
- workflowId: review-topic-capacity
  summary: Audit a topic's partition and replica layout against the cluster's brokers.
  description: >-
    Reads cluster, brokers, topic inventory, and per-partition replica placement
    for a single topic so capacity and durability can be assessed together.
  inputs:
    type: object
    required:
    - clusterId
    - topicName
    properties:
      clusterId:
        type: string
        description: The Kafka cluster id to audit.
      topicName:
        type: string
        description: The topic to drill into for partition and replica detail.
  steps:
  - stepId: readCluster
    description: >-
      Read the cluster to confirm it exists and to capture the controller
      reference that anchors the rest of the audit.
    operationId: getCluster
    parameters:
    - name: cluster_id
      in: path
      value: $inputs.clusterId
    successCriteria:
    - condition: $statusCode == 200
    outputs:
      clusterId: $response.body#/cluster_id
      controller: $response.body#/controller
  - stepId: listBrokers
    description: >-
      List the brokers in the cluster. The broker count is the hard ceiling on
      any topic's replication factor and the baseline for judging replica
      spread.
    operationId: listBrokers
    parameters:
    - name: cluster_id
      in: path
      value: $steps.readCluster.outputs.clusterId
    successCriteria:
    - condition: $statusCode == 200
    outputs:
      brokers: $response.body#/data
  - stepId: listTopics
    description: >-
      Inventory the cluster's topics, giving the audit the full picture of what
      is deployed before narrowing to one topic.
    operationId: listTopics
    parameters:
    - name: cluster_id
      in: path
      value: $steps.readCluster.outputs.clusterId
    successCriteria:
    - condition: $statusCode == 200
    outputs:
      topics: $response.body#/data
  - stepId: readTopic
    description: >-
      Read the target topic's declared partition count and replication factor,
      which is what the audit compares against the broker list.
    operationId: getTopic
    parameters:
    - name: cluster_id
      in: path
      value: $steps.readCluster.outputs.clusterId
    - name: topic_name
      in: path
      value: $inputs.topicName
    successCriteria:
    - condition: $statusCode == 200
    outputs:
      partitionsCount: $response.body#/partitions_count
      replicationFactor: $response.body#/replication_factor
      isInternal: $response.body#/is_internal
  - stepId: readPartitions
    description: >-
      Read the per-partition detail, exposing the leader and replica set for
      each partition. This is where leader skew and under-replication become
      visible.
    operationId: listPartitions
    parameters:
    - name: cluster_id
      in: path
      value: $steps.readCluster.outputs.clusterId
    - name: topic_name
      in: path
      value: $inputs.topicName
    successCriteria:
    - condition: $statusCode == 200
    outputs:
      partitions: $response.body#/data
  outputs:
    brokers: $steps.listBrokers.outputs.brokers
    topics: $steps.listTopics.outputs.topics
    partitionsCount: $steps.readTopic.outputs.partitionsCount
    replicationFactor: $steps.readTopic.outputs.replicationFactor
    partitions: $steps.readPartitions.outputs.partitions

Work with this as data

Every workflow here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for arazzo workflows

4 MCP tools reach this
  • find_arazzoBrowse and filter every workflow in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This workflow
curl "https://apis.io/api/v1/arazzo/apache-kafka-topic-capacity-review-workflow"
All arazzo workflows
curl "https://apis.io/api/v1/arazzo?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.