This week’s issue brings you:

• How to Approach Scaling Your Database

• API Gateway vs Load Balancer — What's the Difference? (Recap)

• What Is Version Drift, And How To Stay Ahead Of It  (Recap)

• API Design Best Practices (Recap)

READ TIME: 5 MINUTES

How to Approach Scaling Your Database

If your application is experiencing load problems, it's time to bring out the champagne! Your app's growing pains are actually a sign of its success.

As the user base expands, so do the demands on your system. You may notice database queries become sluggish, network requests time out, and user interfaces start to lag.

These signs indicate that it's time to scale your infrastructure to keep up with demand.

Today we’ll be honing in on how to approach scaling your database. Let’s jump in.

The Cost of Scaling

Before you start you start diving into implementing scaling solutions, an important principle should be kept in mind.

You shouldn’t implement premature optimizations or attempt to scale your app before it’s actually needed.

Implementing scaling solutions introduces complexities, including:

• New features take longer to develop

• The system becomes more complex with more pieces and variables involved

• Code can be more difficult to test

• Finding and resolving bugs becomes harder

You should only accept these trade-offs if your app is reaching capacity. Keep the system simple, don’t introduce scaling complexities unless it’s warranted.

Finding Bottlenecks Using Metrics

To scale effectively, first, identify your bottlenecks.

Time to check your resource monitoring system or create one if you haven’t already.

If you’re running on any of the leading IaaS providers, such as AWS and Azure, there are already application performance management tools available out of the box.

Analyze and observe resource usage. Pinpoint what’s holding your app back. Look for spikes or flat tops in your monitoring tools, indicating that a resource is overwhelmed.

If performance issues aren't immediately apparent, but your app seems to be running slow, try sprinkling logs in heavily used operations to check for slow-loading resources.

This analysis will guide your scaling strategy, ensuring you address the right problems.

Scaling an App From a Birdseye View

Now that we’ve got a good sense of what/where the problems/bottlenecks are, we can start implementing solutions to address these issues.

Remember, simplicity is key, we want to avoid introducing unnecessary complexities.

The high-level goal of scaling solutions is to have the stack do less work for the application’s most common requests or effectively distribute across multiple resources the workload that can’t be eliminated.

The way that scaling techniques do this usually translates into one or more of the following:

• Reusing data the app has already looked up

• Eliminating requests from the client for data the app already possesses

• Storing results of common operations in order to reduce repeating computations

• Avoiding complex operations in the request-response cycle

Many scaling techniques boil down to some form of caching.

Cache Database Queries

Caching database queries is one of the simplest improvements you can make to handle database load.

Usually, an application will have a handful of queries that make up the majority of the requests made.

Rather than making a round trip over the network each time for that data, it can simply be cached in memory on the webserver.

To take it one step further, it can be cached in a dedicated in-memory store such as Redis.

Data that’s cached can become ‘stale’ or out of date quite quickly. You will have to be mindful of which data you chose to cache and how long for.

Database Indexing

Proper indexing is another efficient lower hanging fruit to enhance performance.

Indexes help locate data quickly without scanning the entire database, significantly speeding up query times.

It’s another simple “early on” solution that provides outsized returns.

However, maintaining the right balance in indexing is important.

Overly indexed databases can slow down because each insert, update, or delete operation requires additional processing to update the indexes. This can lead to slower write performance and increased storage requirements.

Database Read Replication

If your database is still under heavy read load even after implementing caching, and efficient indexing, considering read replication can often be a next step.

Read replication involves writing to a single primary database, which is then cloned into multiple read replicas on different machines.

This distributes the read load across several servers, taking the pressure off the primary database and improving write performance.

Additionally, having replicas in different regions can dramatically increase read speed and reduce latency.

However, writes to the primary database need to propagate to the replicas, which can lead to temporary data inconsistencies. For immediate read-after-write consistency, such as updating and immediately viewing a profile, read from the primary database.

Read replication is a powerful scaling solution but comes with its fair share of complexities. It's advisable to implement it only after exhausting simpler solutions and ensuring optimal application performance.

Database Sharding

Most scaling solutions focus on reducing database read loads.

Database sharding, however, manages both reads and writes by partitioning the primary database into multiple smaller databases (shards). This horizontal scaling technique splits data across multiple nodes or servers.

There are two types of sharding: horizontal and vertical.

Horizontal sharding involves placing rows across different machines with identical columns.

Vertical sharding splits a table into distinct tables with separate rows and columns across multiple machines.

Sharding can speed up queries and improve resilience to failures, as an outage typically affects only a single shard rather than the entire database.

Database sharding is powerful and carries a lot of benefits. However, sharding is complex and costly to implement and maintain. It should be considered after exhausting other scaling solutions as the ramifications of ineffective implementation can be quite severe.

Leveraging DBaaS for Efficient Scaling

These days a lot of the manual implementation can be abstracted away.

Database as a service (DBaaS) solutions, including Amazon RDS, Google Cloud SQL, and Microsoft Azure SQL Database, offer scalable database management with minimal manual intervention.

These services facilitate the scaling process (both vertical and horizontal) with automation features, enabling you to concentrate more on optimizing your application and less on intensive infrastructure management.

Wrapping Up

Scaling your database effectively involves more than just throwing resources at the problem.

It requires a strategic approach tailored to your specific challenges.

There are general patterns, best practices, and solutions that are typically applied early on and later on.

As you plan your scaling strategy, remember that each step not only addresses immediate needs but also sets the groundwork for sustained growth.

API Gateway vs Load Balancer — What's the Difference? (Recap)

API gateways focus on request management and microservice communication, while Load balancers focus on traffic distribution and server load management.

API gateways operate at the application layer (L7), while Load balancers can operate at both transport (L4) or application (L7) layers.

API gateways offer features like routing, rate limiting, authentication, service discovery, parameter validation, circuit breakers, and more, while Load balancers handle traffic distribution.

API gateways are ideal for microservice architectures needing centralized API management, while Load balancers are essential for applications requiring high availability, distributing traffic across multiple servers.

Check out the full post here for an extended explanation.

What Is Version Drift, And How To Stay Ahead Of It (Recap)

Version drift happens when two systems that depend on each other differ. Like your app and an external API falling out of sync because one side changes and the other doesn’t keep up.

It often shows up as silent breakage, eg; the API changes its response format, but your code still expects the old version. Since changes aren’t always communicated clearly or tested against in real time, drift builds up until something breaks, often in production.

Check out the full post here on how to stay ahead of version drift (before it breaks production).

API Design Best Practices (Recap)

There are several aspects, techniques, and best practices in API design.

Idempotency, security, versioning, clear resource naming, use of plurals, cross-referencing resources, sorting, and filtering are all aspects that can be observed in the URL.

However, best practices go far beyond what can be observed in API URLs.

Thorough documentation, robust monitoring and logging, consistent error handling, and rate limiting some of the other primary best practices that should be implemented to design effective and safe APIs.

For an explanation of the best practices mentioned above, check out the full post here.

That wraps up this week’s issue of Level Up Coding’s newsletter!

Join us again next week, where we’ll explore and visually distil more important engineering concepts.