# Ordering Service

## Introduction

Many distributed blockchains, such as Ethereum and Bitcoin, are not permissioned, which means that any node can participate in the consensus process, wherein transactions are ordered and bundled into blocks. Hyperledger Fabric works differently, as transaction ordering is handled by a so-called **Ordering Service**. An Ordering Service is an entity that governs transaction ordering for one or more Channels through its nodes, called **orderers** or **orderer nodes**.

Ordering Services exist independent of the peer processes and orders transactions on a first-come-first-serve basis for all channels on the network. 

In basic scenarios, a single Ordering Service is defined to handle transaction ordering for all Channels in the Network. However, Hyperledger Fabric supports multiple Ordering Services for one Network, even with different Consensus Protocols.

At the moment, the only consensus algorithm available on the platform is Raft. Raft offers a generic way to distribute a state machine across a cluster of computing systems, ensuring that each node in the cluster agrees upon the same series of state transitions. With the next updates, you will also find Kafka.

## Configuration

Double click on the Ordering Service to edit it.

<figure><img src="https://t-images.imgix.net/https%3A%2F%2Fapp-us-east-1.t-cdn.net%2F5f96e1a6e5864f172c21948d%2Fposts%2F61e5a2dc124e18d7a38d2a86%2F61e5a2dc124e18d7a38d2a86_95848.png?width=1240&#x26;w=1240&#x26;auto=format%2Ccompress&#x26;ixlib=js-2.3.1&#x26;s=c16a89aeb8f2bd05cf09affe0436126e" alt=""><figcaption></figcaption></figure>

<figure><img src="https://t-images.imgix.net/https%3A%2F%2Fapp-us-east-1.t-cdn.net%2F5f96e1a6e5864f172c21948d%2Fposts%2F61e5a2f4ac8d7edef8d20891%2F61e5a2f4ac8d7edef8d20891_11089.png?width=1240&#x26;w=1240&#x26;auto=format%2Ccompress&#x26;ixlib=js-2.3.1&#x26;s=4ff905ad875c0ead422282f50bea270c" alt=""><figcaption></figcaption></figure>

### Settings

* **Name**: defines the Ordering Service’s name (Ordering Service Name must be set);
* **Consensus Type**: defines which implementation will be used by this Ordering Service to determine Consensus (the Consensus Type can be “Raft” or “Kafka”);
* **Add Policy**: custom policy setting is not yet implemented. It will be implemented in the coming updates (Policies for this Ordering Service must be set).
* **Organization**: defines to which Orderer Organization this Ordering Service belongs (Organization must be set).

{% hint style="info" %}
Notes:

* “Orderers” defines the number of Orderer Nodes belonging to this Ordering Service (Orderer Nodes must be set).
* The Ordering Service must be assigned to a Channel.
* Names must contain only alphanumeric characters or '\_' and be 20 characters at most.
  {% endhint %}

For higher crash/fault tolerance and redundancy, it is advised that an Ordering Service is defined with at least 2 Orderer Nodes. Since Ordering Services might be serving multiple Channels, one should also consider scaling the amount of Orderer Nodes to match this eventuality.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.astrakode.tech/akb-wiki/astrakode-wiki/network-composer/components/ordering-service.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.