Asynchronous processing - Deepstash

Keep reading for FREE

Asynchronous processing

Asynchronous processing

Slow operations should be done asynchronously to avoid making users wait for long periods of time until their requests are processed.

Sometimes this can be done in advance, by pre-processing data that you know users will need. For example, a forum might periodically re-render its page of most popular posts and the number of comments.

Asynchronous processing usually requires 2 components:

  1. A queue that stores tasks, ordered by time and priority
  2. Aย system that processes tasks

Networking metrics

Networking metrics

  • Bandwidth - Maximum amount of data that can be transferred in a unit of time. Usually expressed in bits per second.
  • Throughput - Amount of data that is actually transferred in a unit of time.
  • Latency - How long it takes data to go from one end to the other.

Database denormalization

Database denormalization

Joins in relational databases get very slow as the system grows bigger. You should denormalize your data to avoid joins and speed up your queries.

Normalized databases are designed to minimize redundancy, while denormalized databases are designed to optimize read time.

Caching

Caching

Caching systems are usually in-memory key-value databases that provide very fast access to data. They sit between your application and the database.

Depending on your use case, you can either cache only the results of the database queries, or cache the entire response objects (such as fully rendered web pages).

Scaling

Scaling

Systems can be scaled:

  • Vertically - by increasing the resources of a specific node (more CPU, memory, disk etc.). This is easier to do, but it's limited. You can only add so many CPU cores and memory.
  • Horizontally - by adding more nodes of the same kind. This usually requires adding a load balancer in front of your nodes to distribute the load evenly.

Database sharding

Database sharding

Sharding means splitting your data across multiple nodes. This can be done in different ways:

1. Vertical sharding

  • Store tables on different nodes.
  • Drawback: If one of these tables gets very large, then you need to re-shard that database.

2. Key-based sharding

  • Use part of your data (usually the row ID) to shard it.
  • Drawback: The number of nodes is fixed. If you want to add more nodes, then you have to reallocate the data.

3. Directory-based sharding

  • Maintain a lookup table for where each data is found.
  • Drawback: The lookup table is a single point of failure, that's constantly under load.

It's time to
Read like a Pro.

Jump-start your

reading habits

, gather your

knowledge

,

remember what you read

and stay ahead of the crowd!

Save time with daily digests

No ads, all content is free

Save ideas & add your own

Get access to the mobile app

2M+ Installs

4.7 App Rating