README.md in avro_turf-0.5.0 vs README.md in avro_turf-0.6.0

@@ -89,5 +89,30 @@
 ```
 
 There's no reason to copy-paste the `person` schema into the `person_list` schema, as you can reference it directly.
 
 This feature helps avoid subtle errors when the same type is represented using slightly different schemas.
+
+
+### Using a Schema Registry
+
+By default, AvroTurf will encode data in the Avro data file format. This means that the schema used to encode the data is prepended to the output. If you want to decrease the size of the output, e.g. when storing data in a log such as Apache Kafka or in a database, you can use the `AvroTurf::Messaging` API. This top-level API requires the use of [Schema Registry](https://github.com/confluentinc/schema-registry), a service which allows registering and fetching Avro schemas.
+
+The Messaging API will automatically register schemas used for encoding data, and will fetch the corresponding schema when decoding. Instead of including the full schema in the output, only a schema id generated by the registry is included. Registering the same schema twice is idempotent, so no coordination is needed.
+
+**NOTE:** The Messaging format is _not_ compatible with the Avro data file API.
+
+Using the Messaging API is simple once you have set up a Schema Registry service:
+
+```ruby
+# You need to pass the URL of your Schema Registry.
+avro = AvroTurf::Messaging.new(registry_url: "http://my-registry:8081/")
+
+# The API for encoding and decoding data is similar to the default one. Encoding
+# data has the side effect of registering the schema. This only happens the first
+# time a schema is used.
+data = avro.encode({ "title" => "hello, world" }, schema_name: "greeting")
+
+# When decoding, the schema will be fetched from the registry and cached. Subsequent
+# instances of the same schema id will be served by the cache.
+avro.decode(data) #=> { "title" => "hello, world" }
+```