anchor.diff:  }
   ```
   
  -then, this has to be configured in a multi binder scenario as the following:
  +then, this has to be configured in a multi binder scenario as the following.
  +Please note that this is only needed if you have a true multi-binder scenario where there are multiple processors dealing with multiple clusters within a single application.
  +In that case, the binders need to be explicitly provided with the bindings to distinguish from other processor's binder types and clusters.
   
   ```
   spring.cloud.stream.binders.kafka1.type: kstream
  
positive.code: }
  ```
  
  This is a rudimentary implementation, however, you have access to the key and value of the record, the topic name and the total number of partitions.
  Therefore, you can implement complex partiioning strategies if need be.
  
  You also need to provide this bean name along with the application configuration.
  
negative.code: 
  The programming model remains the same, however the outbound parameterized type is `KStream[]`.
  The default output binding names are `process-out-0`, `process-out-1`, `process-out-2` respectively.
  The reason why the binder generates three output bindings is because it detects the length of the returned `KStream` array.
  
  ===== Summary of Function based Programming Styles for Kafka Streams
  
  In summary, the following table shows the various options that can be used in the functional paradigm.
  
  