Using multipart upload provides the following advantages:

Improved throughput – You can upload parts in parallel to improve throughput.

Quick recovery from any network issues – Smaller part size minimizes the impact of restarting a failed upload due to a network error.

Pause and resume object uploads – You can upload object parts over time. After you initiate a multipart upload, there is no expiry; you must explicitly complete or stop the multipart upload.

Begin an upload before you know the final object size – You can upload an object as you create it.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html

So please revisit your requirement/chnages.

Ok, but at the same time I personally consider 1k+ req/s a bit of overkill.

Based on what others do (ex. boto3 has default concurrency setting of 10)

https://github.com/boto/boto3/blob/93978170acb80cf7b6ff85c3a9b657e2022bb9fb/boto3/s3/transfer.py#L260-L261

I've implemented similar limit here...

@prakashsvmx I've just tried to run this 1k parts compose test against play.min.io using this little test inway/minio-compose-object with BUCKET_NAME set to minio-compose-object (I've already populated this bucket with parts) so feel free to test it on your own.

After setting minioClient.traceOn(); on Minio client you can see that it hits 429 status pretty fast...