DEV Community: Anurag choudhary

Database Scaling NLogN 📈

Anurag choudhary — Sun, 29 Dec 2024 20:29:20 +0000

What is Database Scaling?

Database scaling refers to the process of increasing a database's capacity to handle growing workloads, such as higher numbers of queries, larger datasets, or more concurrent users.
The primary goal is to ensure the database maintains performance, reliability, and availability as demand increases.

There are two primary types of database scaling:

⬆️ Vertical Scaling (Scaling Up)
➡️ Horizontal Scaling (Sharding)

🤔 Why Do We Need Database Scaling?

Suppose your current database server can handle up to 1000 queries per second (QPS). What happens if your website traffic spikes due to a new feature launch or increased popularity? Without scaling, your database will eventually fail under the load.
Scaling ensures that your database can meet the growing demands of your application, balancing data distribution, optimizing resources, and maintaining cost efficiency.

❓Why Not Just Use Master-Slave Replication?

If you're familiar with master-slave replication, you might think it eliminates the need for scaling. (If not, check out my blog post on Database Replication NLogN👈 to learn more). While replication is effective for scaling reads and providing fault tolerance, it doesn't solve all challenges:

Write Bottlenecks: Replication doesn't improve write capacity since all writes must still go to the master
Hotspots: Frequently accessed data can overload specific nodes
Scaling Limits: Replication doesn't address global traffic distribution needs

🛠️ Types of Database Scaling

1.⬆️ Vertical Scaling (Scaling Up)

Vertical scaling involves upgrading the existing database server by adding more hardware, such as additional CPU, RAM, or storage.

Why Can't We Keep Adding More Hardware?

High Costs: High-end servers are exponentially more expensive
Hardware Limitations:
- Limited motherboard slots for RAM
- Restricted cores and threads in CPUs
Single Point of Failure: One server creates critical risk
Scalability Ceiling: Hardware improvements have physical limits

2.➡️ Horizontal Scaling (Sharding)

Horizontal scaling involves distributing data across multiple servers to divide the load. Each server (or shard) stores a unique subset of the data.

How Does Sharding Work?

Data is allocated to servers based on a sharding key. For example:

Use a hash function like user_id % 4 to determine which shard handles specific user data
Shard 0 stores data for users where the result is 0, and so on

Benefits of Sharding

Distributes load evenly across multiple servers
Allows indefinite scaling by adding more shards

Challenges of Sharding

Resharding Data: Redistributing data across new shards when capacity is reached
Celebrity Problem: Disproportionate traffic to specific shards
Joins and Denormalization: Difficulty in performing cross-shard joins
Complex Application Logic: Applications must route queries correctly

📋 When to Choose Replication vs. Scaling?

Use replication for read-heavy workloads and fault tolerance
Use scaling for growing traffic and write-heavy workloads

🎯 Conclusion

Scaling your database is crucial for supporting rapidly increasing data traffic and ensuring high availability. Whether you choose vertical scaling or horizontal scaling, the decision depends on your specific requirements and growth projections.

🔮 Coming Next

Stay tuned for our next blog on message queues and data centers, two powerful techniques for reducing latency and improving application performance!

CDN NLogN🌍

Anurag choudhary — Thu, 21 Nov 2024 19:09:15 +0000

What is a CDN?

CDN (Content Delivery Network) is a globally distributed network of servers designed to deliver static content quickly and efficiently. In simpler terms, think of a CDN as servers located closer to users that cache static assets like images, videos, CSS, and JavaScript files.

Why Do We Need a CDN?

Imagine setting up servers in every user region to reduce latency—it’s not only impractical but also incredibly expensive. This is where CDNs shine. They:

Reduce latency by bringing content closer to users.
Increase availability by offloading the workload from your main servers.

Dynamic tasks like API calls or database queries are typically handled by origin servers, while static content is served through the CDN. In some cases, CDNs can even cache dynamic data depending on the use case.

How Does a CDN Work?

When a user visits a website, the CDN server nearest to them delivers the requested static content. The closer the CDN server, the faster the content loads. For example:

Users in Delhi will experience faster loading speeds if the CDN server is in Noida.
However, users in Bengaluru might experience slower speeds if the nearest CDN server is located in Delhi.

Instead of making direct requests to the origin server for every file or data, the CDN handles the delivery. This reduces the load on your servers, minimizes latency, and ensures higher availability.

Key Considerations When Using a CDN

Cost

CDNs are managed by third-party providers and incur charges for data transfers in and out of the network. Caching rarely accessed assets might not provide much value, so consider excluding those files.
CDN Fallback

Plan for potential CDN outages. Ensure that your application can gracefully request resources from the origin server if the CDN is temporarily unavailable.
Cache Expiry Settings
- For time-sensitive content, set an appropriate cache expiry duration.
- If it’s too long, users may receive outdated content.
- If it’s too short, frequent reloads from the origin server can negate CDN benefits.
Invalidating Files
- Invalidate the CDN object via APIs provided by the CDN vendor.
- Use object versioning by appending parameters to the URL (e.g., image.png?v=2) to serve updated content.

Conclusion

In today’s digital-first world, users expect lightning-fast load times. A CDN not only helps meet these expectations but also scales effortlessly as your audience grows. By reducing latency, enhancing availability, and offloading server strain, a CDN becomes an indispensable part of modern web architecture.

So, whether you're serving static assets or caching specific dynamic data, a well-optimized CDN can significantly elevate your application's performance.

Stay tuned for more insights! 🚀

Cache NLogN🏎️

Anurag choudhary — Fri, 01 Nov 2024 09:33:00 +0000

What is a Cache?

A cache is a temporary storage area that keeps results from expensive operations or frequently accessed data in memory, so future requests are served much faster. It's a powerful tool to enhance application performance by minimizing direct database calls.

Why Cache? 🤔

Instead of making repeated calls to the database or doing expensive calculation, we can retrieve data from the cache. But what’s the real benefit?

Low Response Time
Resource Savings
Enhanced Application Performance

Then, why don’t we store everything in the cache for ultimate speed?

Cache memory is volatile — it doesn’t persist data.
Cache has limited capacity — far less than databases.

To maximize efficiency, we only store high-cost or frequently accessed data in cache, minimizing repetitive database calls or heavy calculations.

Cache Tier 🗂️

A cache tier is a super-fast, temporary data layer that sits between your app and the database. The benefits of having a separate cache tier include better system performance, ability to reduce database workloads, and the ability to scale the cache tier independently

How Does It Work?

Web server receives a request
Checks if data exists in cache
If yes → Returns data to client
If no → Queries database → Stores in cache → Returns to client

This strategy is known as a read-through cache.

When to Use Cache?

Consider caching when:

Data is frequently read but rarely modified.

Since cache data is stored in volatile memory, it’s unsuitable for persisting data. If the cache server restarts, all in-memory data is lost. Critical data should always reside in a persistent data store.

Important Cache Considerations 📝

Expiration Policy: It is a good practice to implement an expiration policy. Once cached data is expired, it is removed from the cache. When there is no expiration policy, cached data will be stored in the memory permanently. It is advisable not to make the expiration date too short as this will cause the system to reload data from the database too frequently. Meanwhile, it is advisable not to make the expiration date too long as the data become Stale.
Consistency: This involves keeping the data store and the cache in sync. Inconsistency can happen because data-modifying operations on the data store and cache are not in a single transaction.
Mitigating Failures: A single cache server represents a potential Single Point Of Failure (SPOF) A single point of failure (SPOF) is a part of a system that, if it fails, will stop the entire system from working As a result, multiple cache servers across different data centers are recommended to avoid SPOF. Another recommended approach is to overprovision the required memory by certain percentages. This provides a buffer as the memory usage increases.
Eviction Policy: When cache is full, it evicts data. Least Recently Used (LRU) is a popular eviction policy. Alternatives like Least Frequently Used (LFU) or First In, First Out (FIFO) suit different scenarios.

Best Practices for a Scalable System

Decouple components to minimize dependencies.
Avoid any Single Points Of Failure.
Balance Latency and Consistency
Enable independent Scaling.

Stay tuned for more insights! 🚀

Load Balancer NLogN 🏗️

Anurag choudhary — Sun, 13 Oct 2024 20:19:33 +0000

What is a Load Balancer?

A load balancer acts as a traffic director, routing incoming requests (users) to different servers based on various factors, primarily the current load on each server.

Why are Load Balancers Necessary?

Improved Security: It helps prevent exposure of servers' private IP addresses to internet users by using private IPs for internal communication between servers and the load balancer, while exposing only the public IP to users for communication with the load balancer.
Enhanced Availability: If one of the servers goes offline, the load balancer routes all traffic to another server in the pool, ensuring high availability.
Simplified Scaling: Scaling becomes an easy process as we only need to add more servers to the web server pool, and the load balancer automatically starts to send requests to them.
Optimized Performance: By distributing requests across multiple servers, load balancers prevent any single server from becoming a bottleneck, improving overall system responsiveness.