Spring Boot Read Write Datasource with AWS RDS Read Replicas

How Did We Discover the Need for a Spring Boot Read Write Datasource?

While working on a high-volume retail SaaS platform, our team faced a critical challenge during the holiday shopping season. The system, which managed massive product catalogs, inventory synchronizations and real-time order processing, was heavily reliant on a single AWS RDS MySQL instance. As traffic surged by 300%, the application began experiencing severe latency spikes. We realized that heavy analytical queries and catalog reads were starving the database connection pool, preventing mission-critical write operations—like order placements—from executing successfully.

During our root cause analysis, we encountered a situation where the database CPU utilization consistently hit 95%, primarily driven by complex read queries. The system was fundamentally read-heavy, with an 85/15 read-to-write ratio. It became evident that routing all traffic to a single instance was an architectural flaw for this scale. We needed a reliable strategy to split the traffic using a Spring Boot read write datasource configuration. This challenge inspired the article so other engineering teams can avoid the same bottlenecks and safely implement RDS Read Replicas without causing production downtime.

Why Did the Single MySQL Instance Become a Bottleneck?

The business use case required real-time inventory checks for millions of shoppers while simultaneously allowing warehouse managers to generate large inventory reports. In the initial monolithic architecture, the Spring Boot application utilized a standard HikariCP connection pool pointing to a single Amazon RDS endpoint. Every time a warehouse manager ran a report, it locked rows, consumed memory and tied up connections.

When you rely on a single datasource in a high-concurrency environment, your read and write workloads compete for the same I/O and CPU resources. The application layer was highly available with autoscaled container instances, but the database layer was a single point of contention. To maintain system stability, we needed to offload the read workload to a replica without rewriting thousands of lines of repository code.

What Were the Symptoms of Database Connection Exhaustion?

The failures manifested across multiple layers of the application stack. Our APM dashboards lit up with elevated response times on standard API endpoints. Specifically, we observed the following symptoms:

• Hikari Pool Exhaustion: Application logs were flooded with connection timeout errors, indicating that threads were waiting too long to acquire a database connection.
• Lock Wait Timeouts: Background cron jobs updating inventory statuses began failing because read-heavy transactions were holding shared locks for extended periods.
• High Database CPU: CloudWatch metrics showed the primary MySQL instance sustaining above 90% CPU, leading to query queuing and degraded performance.
• Failing Health Checks: The cascading effect of database latency caused our Spring Boot actuator health endpoints to time out, which temporarily triggered erroneous container restarts by our orchestrator.

How Did We Approach the Solution for Database Scaling?

Before jumping straight into modifying the application configuration, we stepped back to evaluate multiple architectural patterns. When CTOs hire software developer teams to resolve production bottlenecks, they expect a methodical evaluation of trade-offs rather than knee-jerk code changes.

Did We Consider Vertically Scaling the RDS Instance?

Our first thought was simply upgrading the AWS RDS instance class to double the vCPUs and RAM. While this is a fast, zero-code solution, it requires downtime to modify the instance type. Furthermore, vertical scaling has a hard physical ceiling and dramatically increases infrastructure costs without solving the fundamental architectural bottleneck of competing read/write workloads.

Could Distributed Caching Solve the Read Heavy Load?

We evaluated introducing a Redis caching layer for the product catalog. While caching is excellent for static data, our retail SaaS platform dealt with highly dynamic inventory numbers that changed every second. Implementing a robust cache invalidation strategy would have taken weeks of development and carried a high risk of displaying stale inventory to customers.

Was Database Sharding a Viable Option?

We also discussed sharding the database by tenant or geographic region. However, sharding introduces immense operational complexity, requires massive application rewrites and makes cross-tenant reporting exceedingly difficult. It was overkill for our current scale.

Ultimately, we decided to implement AWS RDS Read Replicas alongside a dynamic routing mechanism in the application layer. This approach provided immediate relief to the primary database, required minimal application code changes and offered a highly scalable path forward.

What is a Safe Migration Strategy for a Spring Boot Read Write Datasource?

The most critical requirement from the business was to introduce this architectural change with minimal downtime, a gradual rollout and a fast rollback plan. Here is the step-by-step strategy we followed in production.

Step 1: Provisioning the Infrastructure

We first provisioned the AWS RDS Read Replica from the AWS console. Since AWS handles asynchronous replication, this process required zero downtime on the primary instance. We set up separate security groups and obtained the new endpoint URL.

Step 2: Implementing the Dynamic Routing Logic

We utilized Spring’s native routing capabilities. By extending a specific Spring class, we could intercept the current transaction context and route the connection dynamically.

public class DynamicDataSourceRouter extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        boolean isReadOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
        return isReadOnly ? DataSourceType.REPLICA : DataSourceType.PRIMARY;
    }
}

With this logic, any service method annotated with a read-only transaction flag would automatically lease a connection from the read replica pool.

Step 3: Configuring the Multi-Datasource Setup

We configured two separate Hikari connection pools—one for the primary and one for the replica. We bundled these into our routing datasource and marked it as the primary bean for the application context.

@Bean
public DataSource routingDataSource() {
    Map<Object, Object> targetDataSources = new HashMap<>();
    targetDataSources.put(DataSourceType.PRIMARY, primaryDataSource());
    targetDataSources.put(DataSourceType.REPLICA, replicaDataSource());
    DynamicDataSourceRouter router = new DynamicDataSourceRouter();
    router.setTargetDataSources(targetDataSources);
    router.setDefaultTargetDataSource(primaryDataSource());
    return router;
}

Step 4: The Gradual Rollout and Feature Flagging

To ensure a safe migration, we did not deploy this to all nodes simultaneously. We introduced a configuration-backed feature flag that controlled the datasource routing.

• Phase 1 (Shadow Mode): Deployed the code with the feature flag OFF. The dynamic router was present but defaulted everything to the primary. This proved the new connection pool logic didn’t break startup.
• Phase 2 (Canary Release): We toggled the feature flag ON for a single read-heavy module (the reporting service). We monitored CloudWatch and application logs for replication lag issues.
• Phase 3 (Full Rollout): After verifying metrics for 48 hours, we rolled the feature flag out to all microservices, effectively routing 85% of our traffic to the read replica.

This feature-flag approach guaranteed that if replication lag caused data inconsistencies, we could flip a switch and instantly route all traffic back to the primary database without requiring a redeployment or experiencing downtime.

What Are the Key Engineering Lessons for Database Replica Migrations?

Migrating to a distributed database topology requires careful planning. For leaders looking to hire java developers for scalable architectures, ensuring the team understands these nuances is critical. Here are the lessons we extracted:

• Mind the Replication Lag: AWS RDS asynchronous replication typically has milliseconds of lag, but under heavy write loads, it can spike. Never route immediate read-after-write operations (like loading an order receipt immediately after checkout) to the replica.
• Connection Pool Tuning: You now have two connection pools. Make sure you adjust your maximum pool sizes. The primary pool can often be reduced, while the replica pool might need to be expanded.
• Transaction Boundaries: The routing logic depends entirely on transaction flags. Ensure your developers properly annotate their service methods. A missing annotation means the query defaults to the primary database.
• Monitor Both Endpoints: Set up distinct monitoring alerts for the primary CPU and the replica CPU. Often, teams forget to monitor the replica, leading to silent failures when read traffic surges.
• Graceful Fallback: Consider implementing a fallback mechanism. If the read replica goes offline, your routing logic should ideally failover to the primary to maintain system availability, albeit with degraded performance.

How Can You Summarize This Database Scaling Journey?

Transitioning an existing monolithic application to a Spring Boot read write datasource is a highly effective way to stabilize performance during hyper-growth. By utilizing Spring’s transaction synchronization manager and employing a strategic, feature-flagged rollout, our team eliminated database bottlenecks without incurring a single minute of downtime. The retail SaaS platform easily handled the remainder of the holiday traffic and we established a scalable pattern for future growth. If your organization is facing similar architectural challenges and you need dedicated expertise to execute complex migrations, contact us.

Social Hashtags

#SpringBoot #Java #AWS #AmazonRDS #MySQL #ReadReplica #SaaS #DatabaseScaling #SystemDesign #SoftwareArchitecture #BackendDevelopment #Microservices #CloudArchitecture #JavaDevelopment #Scalability