@RajeshM17245081 If you're using embedded Kafka then you want to make sure the total number of partitions per node with Stream type is under 1000.  Each dedicated Queue Processor will have 2 replicas of the number of partitions configured for that QP (default 6), which are then divided across the Stream nodes.  So for example with 200 QPs and 6 partitions per QP you have 200 * 6 * 2 =2,400 partitions.  With 2 Stream nodes being recommended that would exceed the 1000 limit. If you're using External Kafka then the partition count limit is usually much higher and this will be less of a problem.

You'll also have to consider the number of threads per QP (configured on the QP rule form), which will run on each BackgroundProcessing node. If you had 2 threads configured for each of those 200 QPs then you have 400 threads available for processing on each BackgroundProcessing node.  This consumes some heap space and overhead, but ultimately you want to watch your CPU utilization to make sure the node isn't overloaded.

In general, I've seen a few clients making dedicated QPs for every type of processing they may have and I think this is a design that doesn't scale very well. The best reasons to create dedicated QPs are either for specific processing types that are very high volume (to prevent delays in processing other tasks if they shared a QP), or when an existing QP doesn't meet your configuration needs (# of threads, # of retries, immediate vs delayed processing).  If you find in Admin Studio that most of your QPs are processing very few records in the last hour it may be worth considering consolidating some of those into a single QP.  Especially if you expect to continue adding new QPs with ongoing application development.