OCI Object Storage Request Throttling Diagnosis and Capacity Scaling Guide

1. Introduction

1.1 Solution Overview

OCI Object Storage runs on shared, multi-tenant infrastructure and uses Request Rate Capacity to manage the request rate available to each tenancy in each region. When sustained traffic or short concurrency bursts exceed the available capacity, customers may experience increased latency, reduced backend throughput, and HTTP 429 TooManyRequests responses.

This guide provides a layered solution framework:

Monitoring and Root-Cause Analysis → Retry and Traffic Control → Object and Access Optimization → Request Rate Limit Increase → Multi-Region or Multi-Tenancy Scaling

The framework supports both active production incidents and proactive capacity planning for rapidly growing workloads.

1.2 Objectives

• Determine whether an issue is caused by Object Storage Request Rate Capacity.
• Mitigate short traffic bursts through retries and traffic control.
• Reduce unnecessary requests by optimizing object layout and access patterns.
• Resolve sustained capacity shortages through a well-supported Service Request.
• Create independent capacity boundaries through multi-region or multi-tenancy architecture when required.
• Establish an observable, predictable, and scalable capacity-management model.

1.3 Request Rate Capacity Basics

Object Storage Request Rate Capacity can generally be understood as shared capacity scoped by:

Tenancy × Region

Each tenancy starts with default request-rate capacity in each region, measured in requests per second (RPS).

For regions with three Availability Domains, such as eu-frankfurt-1, uk-london-1, us-ashburn-1, us-phoenix-1, and us-chicago-1:

Read RPS	Write RPS	List RPS
12,000	3,000	2,000

For other regions:

Read RPS	Write RPS	List RPS
5,000	3,000	2,000

Customers requiring higher request rates can contact their OCI Account Team or submit a Service Request through the OCI Console. Requests are generally prioritized for tenancies consuming several petabytes of storage and are evaluated based on storage footprint, request profile, growth trend, business importance, and available regional capacity.

Note: Request Rate Capacity is a Service Level Objective (SLO), not a performance SLA or an absolute guarantee. Clients must still implement appropriate retry, backoff, and traffic-control mechanisms.

1.4 Limit Scope

Resource Boundary	Independent Capacity	Description
Different regions in the same tenancy	Yes	Capacity is regional, but data and requests must be routed to the target region
Parent and child tenancies in an OCI Organization	Yes	Each has an independent namespace, resource boundary, and regional limits
Compartments in the same tenancy	No	Compartments in the same region share tenancy-level request capacity
Buckets in the same tenancy and region	No	Creating additional buckets does not increase total Request Rate Capacity

A limit increase approved for one tenancy should not be assumed to apply automatically to another parent or child tenancy.

1.5 Relationship Between QPS and Bandwidth

OCI does not publish a single fixed tenancy-level Gbps limit for the public Object Storage endpoint. However, every high-RPS workload must also be evaluated for data throughput.

Estimated Throughput (Byte/s)
≈ Request Rate (RPS) × Average Payload (Byte/Request)

Estimated Bandwidth (Gbps)
≈ RPS × Average Payload (Byte) × 8 ÷ 1,000,000,000

QPS and bandwidth are related but do not necessarily grow proportionally:

• Metadata operations such as HeadObject and ListObjects can have high QPS but low bandwidth.
• Large GetObject or PutObject operations can generate both high QPS and high bandwidth.
• Range GET traffic should be calculated using the actual returned bytes rather than the full object size.
• Workloads using Object Storage Private Endpoints must also validate endpoint network throughput.
• Compute shapes, VNICs, Service Gateways, NAT Gateways, and cross-region links can become bottlenecks.

For a major QPS increase, include projected peak Read/Write Gbps in the request so that the Product/Capacity Team can evaluate backend throughput as well.

---

2. Business Scenarios

2.1 Typical Workloads

This solution applies to:

• AI/ML training, inference, and agent applications.
• Data lakes and large-scale analytics.
• Media processing, log storage, and content distribution.
• Backup, archive, and bulk data migration.
• Large numbers of compute nodes accessing Object Storage concurrently.
• Rapid growth in storage capacity, object count, and backend jobs.
• Frequent GetObject, PutObject, HeadObject, or ListObjects calls.
• Online services and background processing sharing the same storage resources.

2.2 Customer Pain Points

When traffic approaches or exceeds current capacity, customers may experience:

• Increased object-read latency and reduced ingestion throughput.
• Backend jobs missing their completion windows.
• Upload, download, or batch-processing timeouts and failures.
• Additional compute nodes failing to improve overall throughput.
• Improper retries creating a retry storm and amplifying traffic.
• Storage and business growth exceeding the scalability of current limits.
• Insufficient API-level RPS, latency, and error monitoring to locate the bottleneck.

HTTP 429 is an important indication of throttling, but root cause should also be assessed using RPS, latency, API type, retry behavior, network conditions, authentication, and authorization errors.

2.3 Common Technical Challenges

Traffic Bursts

Average RPS may remain below the limit while short traffic spikes still trigger throttling.

High-Concurrency Small Objects

A workload can generate very high request rates even when total storage is relatively small if it contains many small objects.

Excessive Metadata Requests

Frequent HeadObject, ListObjects, or object-status checks can consume significant request capacity.

Storage and Request Growth

As storage grows, object count, daily ingestion, downstream reads, backend jobs, and concurrent compute nodes may grow together, causing the current limits to become a production bottleneck.

Insufficient Observability

If only storage capacity is monitored, without peak, P95, and P99 RPS, API distribution, object size, and retry ratio, both root-cause analysis and limit-increase approval become more difficult.

2.4 Business Value

This solution helps customers:

• Reduce the impact of throttling on online services and backend jobs.
• Shorten diagnosis and production-recovery time.
• Avoid unnecessary scaling and costs caused by inefficient retries.
• Identify storage, request-rate, and network-throughput bottlenecks proactively.
• Improve the completeness and approval probability of limit-increase requests.
• Support business growth, new application launches, and large-scale data processing.
• Make measurable tradeoffs between performance, cost, complexity, and scalability.

---

3. Solution

3.1 Confirm the Throttling Root Cause

Before selecting a solution, confirm that the issue is actually caused by Object Storage Request Rate Capacity.

Collect:

• HTTP status codes and OCI Request IDs.
• Request timestamps, target region, bucket, and API operation.
• Actual Read, Write, and List RPS.
• Peak, P95, and P99 RPS.
• Request latency and timeout rate.
• Client concurrency and retry counts.
• Average and P95 object size.
• Peak Read/Write throughput.
• Client-side and server-side logs.

Confirm:

• Which API operation is affected.
• Whether the issue is sustained or burst-related.
• Whether an abnormal client or scheduled job is amplifying traffic.
• Whether retries are increasing the workload.
• Whether the issue is caused by networking, authentication, authorization, invalid parameters, or application errors.
• Whether the bottleneck is QPS, bandwidth, or client-side network capacity.

3.2 Solution One: Client Retry and Traffic Control

This is the first priority for mitigating short-term throttling.

Retry Mechanism

• Prefer the Retry Policy supported by OCI SDKs.
• Implement explicit retries for REST APIs, custom clients, and third-party tools.
• Use exponential backoff and random jitter.
• Set maximum retry counts and cumulative wait times.
• Record and alert on requests that still fail after retry.
• Avoid fixed retry intervals across all clients.

Errors commonly suitable for retry include:

• 429 TooManyRequests.
• Selected transient 5xx errors.
• Temporary network connection or timeout errors.

Do not indiscriminately retry non-recoverable 4xx errors such as authentication failures, authorization failures, invalid parameters, or missing objects.

Traffic Control

• Set per-instance and application-wide concurrency limits.
• Use queues to smooth ingestion and background workloads.
• Apply burst control.
• Schedule non-urgent tasks outside peak periods.
• Prevent failed requests from retrying indefinitely.
• Monitor retries as a percentage of total requests.

Retry handles transient errors and short traffic bursts. It does not solve a sustained workload that continually exceeds available capacity.

3.3 Solution Two: Optimize Object and Access Patterns

Optimize Small Objects

• Combine small objects where appropriate.
• Use file formats suitable for batch processing.
• Select an appropriate multipart-upload part size.
• Avoid creating one object for every very small record.

Reduce Duplicate Reads

• Cache hot objects locally, in the client, or in a distributed cache.
• Use a CDN where appropriate.
• Prevent the same job from downloading identical objects repeatedly.
• Use Range GET to retrieve only the required data range.

Optimize Metadata Requests

• Avoid excessive HeadObject calls.
• Avoid using ListObjects as a business-query interface.
• Store searchable object metadata in a database or index service.
• Cache object-existence, version, and modification information.

Smooth Background Workloads

• Schedule scans, backups, and batch jobs outside peak periods.
• Separate online and offline workloads.
• Limit concurrency for individual jobs.
• Avoid starting the same workload on all compute nodes simultaneously.

3.4 Solution Three: Request a Request Rate Limit Increase

If production traffic continually approaches or exceeds current capacity, submit an increase request through OCI Support, the Account Team, or the applicable internal process.

Request Information

Resource information:

• Tenancy name and OCID.
• Object Storage namespace.
• Target region.
• Current and requested Read/Write/List limits.
• Primary buckets and workload environments.

Capacity and growth:

• Current storage footprint and object count.
• Daily new-object count.
• At least 30 days of historical growth where available.
• A 3-to-12-month capacity forecast.
• The projected date for reaching the next capacity milestone.

Actual request metrics:

• Read/Write/List peak, P95, and P99 RPS.
• Primary API operations and their percentages.
• Average and P95 object size.
• Peak Read/Write Gbps.
• Number of active clients or compute nodes.
• Normal traffic and recovery or failover traffic.

Business impact and justification:

• Throttling timestamps, frequency, and affected APIs.
• Impact on request latency, backend processing, and end users.
• Current and expected business growth.
• New projects, contracts, or launch plans.
• Impact if capacity is not increased.
• Endorsement from Sales, the Account Team, the Product Team, and Capacity/Engineering.

Commonly Missing Information

• A target RPS is provided without a calculation.
• Only server count and estimated per-server RPS are provided.
• The request focuses only on 429 without explaining business impact.
• Storage footprint, object count, and historical growth are omitted.
• Peak, P95, P99, and API distribution are omitted.
• Object size, throughput, and network path are not described.
• Retry, concurrency control, and access optimization are not demonstrated.
• Business forecasts and stakeholder endorsement are missing.

Do not treat “less than 1 PB cannot be increased” as an absolute rule. A more accurate statement is:

Major increases are generally more difficult to approve when the storage footprint is small or the target significantly exceeds the standard workload profile. Strong production metrics, growth forecasts, and business justification are required.

Target Capacity Calculation

Target Capacity
= Current Measured Peak
+ Verifiable Business Growth
+ Failover and Recovery Headroom

Server count and estimated per-server RPS can be included as supporting evidence, but should not be the only basis for the request.

Staged Increase

When the final target is significantly higher than current capacity, request two levels:

Current Limit
→ Immediate Minimum
→ Final Target

• Immediate Minimum mitigates current production impact and near-term growth.
• Final Target supports the future storage footprint, workload scale, and failover scenarios.

A staged increase can reduce initial approval difficulty and provide new operating data for the final request.

Operation-Specific Sublimits

If a capacity report contains Read, Get, Metadata Only Read, Write, Put, Metadata Only Write, and List categories, confirm:

• Which categories include GetObject, PutObject, HeadObject, multipart upload, and copy operations.
• Whether Get and Put are independent operation-specific limits.
• Whether sublimits must be increased together with aggregate Read/Write limits.

If independent sublimits exist, increasing only aggregate Read/Write capacity may not fully remove the bottleneck.

3.5 Solution Four: Architecture Scaling

If retries, access optimization, and limit increases cannot support long-term growth, distribute data and traffic across multiple regions or tenancies.

Multi-Region Distribution

Different regions in the same tenancy have independent Request Rate Capacity, but both data and requests must be routed to the corresponding region.

Implementation options include:

• Create target buckets in additional regions.
• Partition traffic by customer, dataset, geography, or workload.
• Write new data directly to the selected region.
• Use cross-region replication.
• Implement application-level dual writes or directed writes.
• Route reads according to object location.

Evaluate:

• Replication delay and consistency.
• Cross-region transfer and duplicate-storage costs.
• Data-residency and compliance requirements.
• Endpoint routing and failover.
• Multi-region monitoring and operational complexity.

Multi-Tenancy Distribution

Independent parent and child tenancies in an OCI Organization can provide separate resource and request-capacity boundaries.

This approach is suitable when:

• Business units or customers require resource isolation.
• Datasets require independent capacity.
• Security or compliance boundaries must be separated.
• A single tenancy cannot support long-term growth.

Evaluate:

• Cross-tenancy IAM policies and identity management.
• Network, key, and security configuration.
• Data migration and replication.
• Monitoring, auditing, and cost allocation.
• Application routing across namespaces and endpoints.

Compartments and buckets are not independent Request Rate Capacity boundaries. A truly independent tenancy is required to create a separate capacity pool.

Architecture Complexity and Cost

Multi-region and multi-tenancy architectures improve long-term scalability, but increase:

• Data partitioning and routing complexity.
• Replication and consistency management.
• Cross-region transfer and duplicate-storage costs.
• IAM, policy, network, and key management.
• Monitoring, alerting, auditing, and capacity forecasting.
• Application development, failover, and operational costs.

Use these architectures only when their long-term scaling benefits justify the implementation and operating complexity.

3.6 Solution Comparison and Decision Principles

Solution	Primary Problem Addressed	Implementation Speed	Cost/Complexity	Suitable Scenario
Root-cause analysis and monitoring	Identifies the actual bottleneck	Fast	Low	Required for every scenario
Retry and traffic control	Short bursts and transient errors	Fast	Low	Occasional 429 responses or traffic spikes
Object and access optimization	Unnecessary traffic, small objects, metadata overhead	Medium	Medium	Workloads with optimizable request patterns
Limit increase	Sustained capacity shortage	Medium	Medium	Production traffic continually approaches the current limit
Multi-region	Long-term single-region capacity or DR needs	Slow	High	Data and traffic can be partitioned by region
Multi-tenancy	Independent capacity, security, or business boundaries	Slow	High	Long-term resource isolation is required

Recommended priority:

1. Confirm the root cause and establish monitoring.
2. Implement retry, backoff, jitter, and concurrency control.
3. Optimize object layout and access patterns.
4. Submit a complete Limit Increase request.
5. Evaluate multi-region or multi-tenancy architecture for long-term growth.

---

4. Conclusion

OCI Object Storage Request Rate Limit issues should be addressed through layered capacity management rather than a single measure.

• Retry and traffic control mitigate short traffic bursts.
• Object and access optimization reduce unnecessary requests.
• Limit increases resolve sustained capacity shortages.
• Multi-region and multi-tenancy architectures support long-term scaling and resource isolation.
• High-QPS workloads must also evaluate Read/Write Gbps, client networking, and endpoint throughput.

The final objective is to balance service stability, performance, cost, and architectural complexity while establishing an observable, predictable, and scalable Object Storage capacity-management model.