upadhyayprakash/8 Fallacies of Distributed Systems

## 8 Fallacies of Distributed Systems
## 8 Fallacies of Distributed Systems

#### Microservices Architecture:
> *"A collection of loosely coupled, independently deployable, highly maintainable and testable services that are organized around the business capabilities and owned by a small team."*

Do not ignore or assume following parameters while designing for scale.

### Fallacies (Wrong Assumptions):
1. **Network is Reliable**: Failures in communication (due to any reason) usually boils-down to `retransmission`. One way to deal is `Store and Forward` pattern, used by open-source message-broker [RabbitMQ](https://www.rabbitmq.com/features.html)

2. **Latency is Zero**: Latency is `omnipresent`. We can deal with latency by reducing physical distance b/w `Server` and the `Client`. CDN and Edge Computing are doing exactly that. Always try to minimize the round-trips between server and the client. There's a trade-off beteen `Latency` and the `Request Payload` size.

3. **Bandwidth is Infinite**:
When making calls to backend service (and if you're not using Caching efficiently), it's quite easy to hit the limit of channel's bandwidth. Split the request to fetch chunk of data. This will increase round-trips and the resulting `latency`. Make the trade-off judiciously.

4. **Network is Secure**: Trust is the most expensive thing when it comes to Network related security. Breaches keep happening. Take a security-first approach when designing a system and always assess your current system for vulnerabilities. It reaps dividents in future!

5. **Topology doesn't Change**: Nodes in distributed system can become single point of failure (`SPOF`)! Ensuring that data flows in such situations is critical. Use tools like [Zookeeper](https://zookeeper.apache.org/) to keep tracks of nodes and manage them.

6. **There's one Admin**: When systems grow, it depends on other components for its functionality. Managing multiple components of a system and their configurations can be tricky, hence use `IaC` (Infra as Code) tools. Monitor various components and enable `Observability` for better issue debugging.

7. **Transport Cost is Zero**: Do not ignore the Transport cost of a network request. Messages in `JSON` formats could be heavier than `gRPC` or `MessagePack`. Whereas handling such complexity initially is a headache. Make a trade-off about when to optimize.

8. **The network is Homogeneous**: Due to the business need of the system being `interoperable` between frameworks & external services; data transformation is needed and makes your design flexible to future changes.


Source: [Blog](https://architecturenotes.co/fallacies-of-distributed-systems/)

Author: [Mahdi Yusuf](https://architecturenotes.co/author/myusuf3/)
	## 8 Fallacies of Distributed Systems

	#### Microservices Architecture:
	> "A collection of loosely coupled, independently deployable, highly maintainable and testable services that are organized around the business capabilities and owned by a small team."

	Do not ignore or assume following parameters while designing for scale.

	### Fallacies (Wrong Assumptions):
	1. Network is Reliable: Failures in communication (due to any reason) usually boils-down to `retransmission`. One way to deal is `Store and Forward` pattern, used by open-source message-broker [RabbitMQ](https://www.rabbitmq.com/features.html)

	2. Latency is Zero: Latency is `omnipresent`. We can deal with latency by reducing physical distance b/w `Server` and the `Client`. CDN and Edge Computing are doing exactly that. Always try to minimize the round-trips between server and the client. There's a trade-off beteen `Latency` and the `Request Payload` size.

	3. Bandwidth is Infinite:
	When making calls to backend service (and if you're not using Caching efficiently), it's quite easy to hit the limit of channel's bandwidth. Split the request to fetch chunk of data. This will increase round-trips and the resulting `latency`. Make the trade-off judiciously.

	4. Network is Secure: Trust is the most expensive thing when it comes to Network related security. Breaches keep happening. Take a security-first approach when designing a system and always assess your current system for vulnerabilities. It reaps dividents in future!

	5. Topology doesn't Change: Nodes in distributed system can become single point of failure (`SPOF`)! Ensuring that data flows in such situations is critical. Use tools like [Zookeeper](https://zookeeper.apache.org/) to keep tracks of nodes and manage them.

	6. There's one Admin: When systems grow, it depends on other components for its functionality. Managing multiple components of a system and their configurations can be tricky, hence use `IaC` (Infra as Code) tools. Monitor various components and enable `Observability` for better issue debugging.

	7. Transport Cost is Zero: Do not ignore the Transport cost of a network request. Messages in `JSON` formats could be heavier than `gRPC` or `MessagePack`. Whereas handling such complexity initially is a headache. Make a trade-off about when to optimize.

	8. The network is Homogeneous: Due to the business need of the system being `interoperable` between frameworks & external services; data transformation is needed and makes your design flexible to future changes.


	Source: [Blog](https://architecturenotes.co/fallacies-of-distributed-systems/)

	Author: [Mahdi Yusuf](https://architecturenotes.co/author/myusuf3/)