key distributed systems design patterns
The table below summarizes the distributed systems design patterns this article will explore in more detail.
| Design pattern | Description | Use cases |
|---|---|---|
| Ambassador | Single point of communication for application services that acts as a proxy to offload common tasks like logging, retries, and monitoring. | Most distributed environments in which multiple different types of services need to perform similar monitoring tasks. For example, envoy proxy in k8s. |
| Circuit breaker | Intelligent link between dependent services that stops traffic if it detects failures in the downstream service to prevent cascading failures. | Cloud-based distributed systems where multiple services are interdependent and network or other failures are relatively common. |
| Command query responsibility segregation (CQRS) | Uncoupling read and write queries into separate components so that each can scale independently. | Applications with significantly different read and write characteristics, such as e-commerce websites. |
| Event sourcing | Maintaining changes to records as an event log rather than directly modifying the current state of the record. | Systems that need a comprehensive history of changes over time, such as version-control systems. |
| Leader election | Multiple nodes in the system elect one as a "leader" with decision-making responsibilities. | Distributed systems are where a common set of tasks need to be divided among multiple copies of the same component (e.g., distributed databases like MongoDB). |
| Publisher/subscriber | Event publishers and subscribers are independent and communicate through a separate event distribution component. | Systems where the same type of event needs to be acted upon by multiple entities. |
| Sharding | Data is divided into identifiable subparts, or shards, between different nodes. | Database systems in which multiple nodes are deployed to decrease query latencies (e.g., Cassandra). |
https://www.multiplayer.app/distributed-systems-architecture/distributed-systems-design/
CPU Bound
A computer can do a calculation. This calculation requires CPU to work. Processing image, and converting a string to byte are examples of the process that requires calculation. Hence, the limiting factor is the amount of CPU power the machine has. The limit here is the CPU power and number of cores. Basically, more cores equal to more workers. More workers mean more tasks can be done, and the higher the RPS.
In a CPU bound system, we can calculate the number of RPS using this formula:
For example, a server with a total number of cores 4 and task duration 10ms can handle 400 RPS while the same server with task duration 100ms can only handle 40 RPS.
Memory Bound
In a memory-bound system, we can calculate the number of RPS using this formula:
For example, a server with a total RAM 16Gb, tasks memory usage 40Mb, and task duration 100ms can handle 4000 RPS while the same server with task duration 50ms (half the previous one) can handle 8000 RPS.
Memory calculation for system design
https://medium.com/geekculture/how-to-calculate-server-max-requests-per-second-38a39bb96a85
No comments:
Post a Comment