Decoupling Systems with Apache Kafka, Schema Registry and Avro
Confluent Platform

Decoupling Systems with Apache Kafka, Schema Registry and Avro

Matt Howlett

As your Apache Kafka® deployment starts to grow, the benefits of using a schema registry quickly become compelling. Confluent Schema Registry, which is included in the Confluent Platform, enables you to achieve strong decoupling of the systems you integrate via Kafka, in turn allowing your teams to be more agile and create applications that are more robust to change.

Why you want a schema registry

Kafka producers and consumers are already decoupled in the sense that they do not communicate with one another directly; instead, information transfer happens via Kafka topics. But they are coupled in the sense that consumers need to know what the data they are reading represents in order to make sense of it—but this is something that is controlled by the producer! In the same way that Kafka acts as an intermediary for your data, Schema Registry can act as an intermediary for the types of data that you publish to Kafka.

In any non-trivial system, requirements change over time and the schemas needed to satisfy them change accordingly; that is, schemas evolve. This evolution makes this form of coupling even stronger. Not only do consumers need to understand the type of data they are reading today, they also depend on any changes that might be made to this type over time. You can reduce this coupling by defining constraints on the way schemas are allowed to evolve upfront and manage these constraints using Schema Registry as well. Producers agree to adhere to the published evolution rules, and consumers are written to be able to handle any schema that is consistent with them. The downside of this, of course, is that it limits flexibility and adds some overhead due to additional formality. However, the payoff in terms of reduced coupling is usually much greater.

Confluent Schema Registry is built around the Apache Avro serialization format. One of the reasons Avro was selected as the recommended format for use with Confluent Platform is that it has flexible, well-defined rules around schema evolution. Jay Kreps expands on this and other appealing aspects of Avro in his article Why Avro for Kafka Data?

Side Note: Avro is often compared with Protobuf and Thrift, two other commonly used serialization formats. A key way in which Avro differs from these formats is that it requires that the schema used to serialize data be available when parsing it. Protobuf and Thrift do notthe serialized data includes enough meta-information to allow it to be parsed without a schema. But this meta-information is only a partial description of the data. For example, it doesn’t include field names or doc strings, so it doesn’t replace the role of a schema registry. 

Putting it into practice with .NET

In this blog post, we’ll walk through a practical example of how to use Avro and Schema Registry from C#/.NET. We’ll assume that you have a Kafka cluster and Schema Registry up and running already (for more information, refer to the Confluent Platform Quick Start). We’ll also assume that you’re set up to build and run C# applications, either targeting the .NET Framework or .NET Core on your platform of choice.

The .NET Avro serializer and deserializer allow you to work with Avro data in one of two ways:

  1. Via specific classes generated using the avrogen tool
  2. Using the GenericRecord class to read and write records with any schema, without needing to pre-generate any class files

We’ll demonstrate how to use both, starting with GenericRecord, then the specific compiler-generated classes. In general, you’ll find working with the specific classes much simpler, and you should prefer this where possible. Use GenericRecord in scenarios where you need to work dynamically with data of any type.

First, let’s define a schema for a simple log message type. We’ll specify this over two files: one for the LogMessage itself, and the other for the LogLevel enumeration that it depends on:

  "namespace": "MessageTypes",
  "type": "enum", 
  "doc": "Enumerates the set of allowable log levels.",
  "name": "LogLevel", 
  "symbols": ["None", "Verbose", "Info", "Warning", "Error"]

  "namespace": "MessageTypes",
  "type": "record",
  "doc": "A simple log message type as used by this blog post.",
  "name": "LogMessage",
  "fields": [
    { "name": "IP", "type": "string" },
    { "name": "Message", "type": "string" },
    { "name": "Severity", "type": MessageTypes.LogLevel }

The Avro format allows you to specify documentation along with your schemas using the doc attribute. You should make good use of this feature. Schemas should be self-contained—someone using your schema should not need to consult any other source of information. Pro tip: you can auto-generate user-readable documentation for your schemas using the Avrodoc tool.

Below is an example of how to produce a LogMessage message to Kafka conforming to the above schema. (Note: The complete source code for all examples is available on GitHub.)

var config = new Dictionary<string, object>
    { "bootstrap.servers", bootstrapServers },
    { "schema.registry.url", schemaRegistryUrl }

using (var producer = new Producer<Null, GenericRecord>(
  config, null, new AvroSerializer<GenericRecord>()))
    var logLevelSchema = (EnumSchema)Schema.Parse(

    var logMessageSchema = (RecordSchema)Schema

    var record = new GenericRecord(logMessageSchema);
    record.Add("IP", "");
    record.Add("Message", "a test log message");
    record.Add("Severity", new GenericEnum(logLevelSchema, "Error"));
    producer.ProduceAsync("log-messages", null, record)
        .ContinueWith(dr => Console.WriteLine(dr.Result.Error 
            ? $"error producing message: {dr.Result.Error.Reason}"
            : $"produced to: {dr.Result.TopicPartitionOffset}"));


There are a few things worth noting:

  • In addition to the required producer property bootstrap.servers, you’ll need to specify a value for schema.registry.url, which is used by the Avro serializer to communicate with Schema Registry.
  • The Avro specification does not provide a way for one schema file to reference another. However, in order to avoid duplicating the LogLevel schema definition, we need to do this because we’re required to specify it separately when constructing the GenericEnum Severity value. Instead of relying on Avro, we use string substitution in our C# program. The LogMessage schema specified above is not a valid Avro schema prior to doing this substitution.
  • By default, the serializer will automatically register new schemas with Schema Registry where compatibility rules allow. Since we haven’t yet registered any other schema against this topic, our LogMessage schema will be automatically registered before the message is produced.
  • Behind the scenes, each schema registered with Schema Registry is given a unique ID that is prepended to the serialized data in each message sent to Kafka. When a consumer reads a message, it uses this ID to associate the message with the schema that was used to write it. If the consumer encounters data that was serialized with a schema it has not seen yet, it will contact Schema Registry to retrieve the schema.

You can verify that the schema was added to Schema Registry as follows:

curl http://localhost:8081/subjects

> ["log-messages-value"]

Notice that the schema was registered under the name log-messages-value, which is the topic name concatenated with -value. This name is referred to as a subject. Corresponding to any given topic, there are potentially two subjects registered in Schema Registry—one corresponding to the message value and one corresponding to the message key (i.e., the topic name appended with -key).

You can interact with Schema Registry further using its REST API. Something else you might want to do is set the subject compatibility to FULL (by default, it’s BACKWARD):

curl -X PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
    --data '{"compatibility": "FULL"}' \

Full compatibility enforces that any schema written to this subject is both forwards and backwards compatible with older schemas:

  • A schema is backward compatible if it can be used to read data written with a previous version of the schema.
  • A schema is forward compatible if previous versions of the schema can be used to read data written by it.

From the perspective of decoupling producers and consumers, forwards compatibility is very desirable because it ensures consumers will be able to read new versions of data without being updated. Backwards compatibility is important for data destined for archival storage because it ensures that the latest schema can be used to read all historical data.

It’s common to want to evolve a schema by adding another field. Conveniently, the new schema will be both forwards and backwards compatible with the old one, provided you specify a default value for the added fields. For a full set of forwards/backwards compatibility rules, refer to the documentation on data serialization and evolution.

OK, let’s add a tags field to our original schema, and this time we’ll define the LogLevel enum inline:

  "namespace": "MessageTypes",
  "type": "record",
  "doc": "A simple log message type as used by this blog post.",
  "name": "LogMessage",
  "fields": [
    { "name": "IP", "type": "string" },
    { "name": "Message", "type": "string" },
    { "name": "Tags",
      "type": { "type": "map",
                "values": "string"},
                "default": {}},
    { "name": "Severity",
      "type": { "namespace": "MessageTypes",
                "type": "enum",
                "doc": "Enumerates the set of allowable log levels.",
                "name": "LogLevel",
                "symbols": ["None", "Verbose", "Info", "Warning", "Error"]}}

Instead of making use of the GenericRecord class, let’s now use the avrogen tool to generate a C# class corresponding to the new schema. avrogen is available as a .NET Core Global Tool (requires .NET Core 2.1 or above). It can be installed as follows:

dotnet tool install -g Confluent.Apache.Avro.AvroGen

Now, you can run the tool in your project directory:

avrogen -s LogMessage.V2.asvc .

And then use the generated class directly with AvroSerializer:

var config = new Dictionary<string, object>
    { "bootstrap.servers", bootstrapServers },
    { "schema.registry.url", schemaRegistryUrl }

using (var producer = new Producer<Null, MessageTypes.LogMessage>(
  config, null, new AvroSerializer<MessageTypes.LogMessage>()))
        "log-messages", null, 
        new MessageTypes.LogMessage
            IP = "",
            Message = "a test message 2",
            Severity = MessageTypes.LogLevel.Info,
            Tags = new Dictionary<string, string> { { "location", "CA" } }

Or with AvroDeserializer:

var consumerConfig = new Dictionary<string, object>
    { "", Guid.NewGuid().ToString() },
    { "bootstrap.servers", bootstrapServers },
    { "schema.registry.url", schemaRegistryUrl },
    { "auto.offset.reset", "beginning" }

using (var consumer = new Consumer<Null, MessageTypes.LogMessage>(
   consumerConfig, null, new AvroDeserializer<MessageTypes.LogMessage>()))
        += (_, error) => Console.WriteLine($"an error occured: {error.Error.Reason}");

        += (_, msg) => Console.WriteLine($"{msg.Timestamp.UtcDateTime.ToString("yyyy-MM-dd HH:mm:ss")}: [{msg.Value.Severity}] {msg.Value.Message}");


    while (true)

When used in the context of the consumer, the MessageTypes.LogMessage schema is referred to as the reader schema. Messages read by the consumer may contain data that was serialized using this schema or potentially any other schema (referred to as the writer schema). In the event that the reader and writer schemas are different, Avro schema resolution rules will be used to reconcile the difference. If the schemas are incompatible, the consumed message will be delivered via the OnConsumeError event rather than the OnMessage event.

With the above examples, we’ve shown how straightforward it is to use Confluent Schema Registry and Avro serialized data with your .NET applications. People just starting out with Kafka often choose to work with a simple text-based serialization format such as JSON, but as your Kafka deployment starts to grow in complexity, there is a lot to be gained from using a data format that provides strong schema evolution rules and by employing a central schema registry to manage them.

If you enjoyed this article on Confluent Schema Registry and Avro, you might also enjoy:

Subscribe to the Confluent Blog


More Articles Like This

Control Center: Schema Registry
Yeva Byzek

Dawn of DevOps: Managing and Evolving Schemas with Confluent Control Center

Yeva Byzek .

As we announced in Introducing Confluent Platform 5.2, the latest release introduces many new features that enable you to build contextual event-driven applications. In particular, the management and monitoring capabilities ...

S3: Exactly Once
Konstantine Karantasis

From Apache Kafka to Amazon S3: Exactly Once

Konstantine Karantasis .

At Confluent, we see many of our customers are on AWS, and we’ve noticed that Amazon S3 plays a particularly significant role in AWS-based architectures. Unless a use case actively ...

Proto Layout
Tom Seddon

Improving Stream Data Quality with Protobuf Schema Validation

Tom Seddon .

The requirements for fast and reliable data pipelines are growing quickly at Deliveroo as the business continues to grow and innovate. We have delivered an event streaming platform which gives ...

Leave a Reply

Your email address will not be published. Required fields are marked *


  1. Hello,

    Thanks for the article. Maybe I missed something, but “Decoupling” concept is still not clear for me after reading this article. Yes, schema registry can host and manage schema, and avro kafka serde class does a lot to simplify serialization / deserialization activities.
    But in the provided examples both AvroSerializer and AvroDeserializer classes refer to the MessageTypes.LogMessage which is auto generated class from schema. Assuming that AvroSerializer and AvroDeserializer are independent modules, they still need to get definition of the MessageTypes.LogMessage class somewhere. AvroSerializer needs this class definition to construct events, AvroDeserializer needs it do consume and process events.
    So, looks like that these 2 classes are still coupled – them both need to know the schema definition. How it is shared between them? Is it a separate module that holds schema definition / generated schema classes and both AvroSerializer and AvroDeserializer depend on this module?
    Or consumers and producers need to request schema from schema registry in runtime using schema registry REST API? In this case, it is not clear how to use the second “generated classes based” approach since we cannot generate classes in runtime.


    1. A key point is the writer and reader schemas (and corresponding generated classes) may be different. If forwards compatibility is enforced on a topic by schema registry, the producer can write a newer version of the data and consumers that are still expecting an older version will not break. The consumer code can be updated (i.e. stub classes re-generated) on an independent timeline and and schema registry is the only system that needs to be consulted when doing so.

  2. Hello,

    I tried producing like this as a test

    using (var producer = new Producer(config, null, new Confluent.Kafka.Serialization.AvroSerializer()))

    int i = 0;
    while (i < 5)
    var product = new Product() { Value = i };
    DateTime time1 = DateTime.Now;
    var task = producer.ProduceAsync("bizgenics.communication", null, product).Result;
    DateTime time2 = DateTime.Now;
    Console.WriteLine($"Delivered '{task.Value}' to: {task.TopicPartitionOffset}, time: {time2 – time1}");


    without the GenericRecord way, where I entered the schema for the Product class in the schema registry.

    However, upon calling produceAsync method I get an error like this:
    "AvroSerializer only accepts type parameters of int, bool, double, string, float, long, byte[], instances of ISpecificRecord and subclasses of SpecificFixed."

    do you know what im doing wrong?

  3. Is this only available with Confluent Kafka or does this also work with Apache Kafka? So if I used Azure’s HDInsight Kafka cluster can I use this feature? The line between Confluent and Apache Kafka are not clear to me.

    If this is not available on Apache Kafka alone can you describe the alternatives for that scenario and how your solution improves upon that alternative?

    1. Schema Registry is a component of Confluent Platform (Confluent Community License). It isn’t part of the Apache Kafka distribution and (afaik) isn’t available as part of HDInsight. Confluent Platform is essentially a collection of independently deployable components that build on Apache Kafka and work well together to make a more powerful event streaming platform. Note that Schema Registry doesn’t have any dependencies on anything else – so it’s easy for you to run it yourself and ignore all the other components of Confluent Platform that you’re not interested in. Schema Registry was developed because there wasn’t any good alternative. Some companies have built their own equivalent service.

Try Confluent Platform

Download Now

We use cookies to understand how you use our site and to improve your experience. Click here to learn more or change your cookie settings. By continuing to browse, you agree to our use of cookies.