anchor.diff:  
   If Serde inference fails, and no binding level Serdes are provided, then the binder falls back to the `JsonSerde`, but look at the default Serdes for a match.
   
  -Default serdes are configured in the same way as above where it is described under deserializtion.
  +Default serdes are configured in the same way as above where it is described under deserialization.
   
   `spring.cloud.stream.kafka.streams.binder.configuration.default.key.serde`
   `spring.cloud.stream.kafka.streams.binder.configuration.default.value.serde`
  
positive.code: ```
  
  If the topic `outputTopic` has 4 partitions, if you don't provide a partitioning strategy, Kafka Streams will use default partitioning strategy which may not be the outcome you want depending on the particular use case.
  Let's say, you want to send any key that matches to `spring` to partition 0, `cloud` to partion 1, `stream` to partition 2, and everything else to partition 3.
  This is what you need to do in the application.
  
  ```
  
negative.code: 
  * If none of the Serdes provided by Kafka Streams don't match the types, then it will use JsonSerde provided by Spring Kafka. In this case, the binder assumes that the types are JSON friendly.
  This is useful if you have multiple value objects as inputs since the binder will internally infer them to correct Java types.
  Before falling back to the `JsonSerde` though, the binder checks at the default `Serde`s set in the Kafka Streams configuration to see if it is a `Serde` that it can match with the incoming KStream's types.
  
  If none of the above strategies worked, then the applications must provide the `Serde`s through configuration.
  This can be configured in two ways - binding or default.
  
  First the binder will look if a `Serde` is provided at the binding level.
  For e.g. if you have the following processor,
  
  ```
  