High S3 ⁠503 SlowDown⁠ throttling during peak w rites with ⁠deduplicati on.enable=true⁠ (v3.9.0)

Hi James Support Team,

We are running a distributed Apache James deployment (v3.9.0) backed by Cassandra 4.1.x, RabbitMQ 3.x, and AWS S3 as our BlobStore. We are currently load testing.

During our load testing, we observed a distinct issue with S3 throttling:

 With ⁠deduplication.enable=true⁠: We experience recurring ⁠503 SlowDown⁠ error spikes from AWS S3 under high write/spooling throughput.

 With ⁠deduplication.enable=false⁠: The ⁠503 SlowDown⁠ errors disappear entirely under the exact same traffic load.

Because deduplication provides S3 cost and capacity savings, we want to keep it enabled.

We suspect this may be caused by single-partition prefix hot-spotting in S3 when generating content-addressed SHA-256 BlobIds, or synchronous hash calculation bottlenecks under heavy concurrency.

Could you please advise on:

1. Recommended ⁠s3.properties⁠ / ⁠blob.properties⁠ tuning for content-addressed deduplicated BlobStores at scale (e.g., prefix hashing / sub-bucket routing configurations to distribute S3 partition keys).

2. Recommended AWS SDK / connection pool settings (such as ⁠objectstorage.s3.http.concurrency⁠ or retry/backoff policies) inside James to gracefully handle S3 rate limits.

3. Any known fixes or improvements in more recent James releases regarding BlobStore deduplication and S3 partitioning.

Thanks in advance for your guidance!