adjust content

chapter-06/README.md

@@ -601,11 +601,11 @@ if (isAlive(metadata.activeHost())) { (2)
 As you can see, this ability to query standby replicas ensures our application is highly available, even when the active instance is down or unable to serve queries. This wraps up our discussion of how to mitigate the impact of rebalances. Next, we’ll discuss custom state stores.
 
 ## Custom State Stores
-It’s also possible to implement your own state store. In order to do this, you need to implement the StateStore interface. You can either implement this directly or, more likely, use one of the higher-level interfaces like KeyValueStore, WindowStore, or SessionStore, which add additional interface methods specific to how the store is intended to be used.[^12]
+It’s also possible to implement your own state store. In order to do this, you need to implement the **StateStore** interface. You can either implement this directly or, more likely, use one of the higher-level interfaces like **KeyValueStore**, **WindowStore**, or **SessionStore**, which add additional interface methods specific to how the store is intended to be used.[^12]
 
-In addition to the StateStore interface, you will also want to implement the StoreSupplier interface, which will contain the logic for creating new instances of your custom state store. Since the performance characteristics of the built-in RocksDB-based state stores are hard to match, it’s typically not necessary to go through the very tedious and error-prone task of implementing your own custom store. For this reason, and given the sheer amount of code that would be needed just to implement a very basic custom store, we will instead point you to one of the few examples of a custom store on [GitHub](https://github.com/confluentinc/kafka-streams-examples/blob/5.4.1-post/src/main/scala/io/confluent/examples/streams/algebird/CMSStore.scala).
+In addition to the **StateStore** interface, you will also want to implement the **StoreSupplier** interface, which will contain the logic for creating new instances of your custom state store. Since the performance characteristics of the built-in RocksDB-based state stores are hard to match, it’s typically not necessary to go through the very tedious and error-prone task of implementing your own custom store. For this reason, and given the sheer amount of code that would be needed just to implement a very basic custom store, we will instead point you to one of the few examples of a custom store on [GitHub](https://github.com/confluentinc/kafka-streams-examples/blob/5.4.1-post/src/main/scala/io/confluent/examples/streams/algebird/CMSStore.scala).
 
-Finally, if you do decide to implement a custom store, be aware that any storage solution that requires a network call could potentially greatly impact performance. One of the reasons RocksDB or a local, in-memory store is a good choice is because they are colocated with the streams task. Of course, your mileage will vary based on your project’s requirements, so ultimately, just be sure to define your performance targets up front and choose your state store accordingly.
+Finally, if you do decide to implement a custom store, be aware that `any storage solution that requires a network call could potentially greatly impact performance`. One of the reasons RocksDB or a local, in-memory store is a good choice is because they are colocated with the streams task. Of course, your mileage will vary based on your project’s requirements, so ultimately, just be sure to define your performance targets up front and choose your state store accordingly.
 
 # Summary
 You should now have a deeper understanding of how state stores are internally managed by Kafka Streams, and what options are available to you, as the developer, for ensuring your stateful applications run smoothly over time. This includes using tombstones, aggressive topic compaction, and other techniques for removing old data from state stores (and therefore reducing state reinitialization time). Also, by using standby replicas, you can reduce failover time for stateful tasks and also keep your application highly available when a rebalance occurs. Finally, rebalancing, while impactful, can be avoided to some extent using static membership, and the impact can be minimized by using a version of Kafka Streams that supports an improved rebalance protocol called incremental cooperative rebalancing.