System Design || Microservice architecture - ashish-ghub/docs GitHub Wiki

Architecture

System Design :

Want to learn system design, focus on the following fundamentals:

1- Database ACID, Data Partitioning and Sharding, SQL vs. NoSQL - https://lnkd.in/gaXpCD_f

2- Proxies, Load Balancer, API Gateway Forward vs Reverse Proxies - https://lnkd.in/gfzyT42k

3- Messaging Systems Queues, Pub-Sub - https://lnkd.in/gJjfRs3k

4- API REST vs. GraphQL vs. gRPC - https://lnkd.in/gwhq6XCZ

5- Replication Synchronous vs. Asynchronous vs. Semi-synchronous replication - https://lnkd.in/g3bp5cfD

6- Caching Cache Replacement Policies, Cache Invalidation Strategies, CDN - https://lnkd.in/gMSr8wTg

7- CAP and PACELC Theorems - https://lnkd.in/gDWwbu9q

Domain Driven Design:

pattern-microservices

Designing microservices architecture for failure Must Read !!!

Making Your Microservices Resilient and Fault Tolerant

Identify Failure Scenarios
Avoid Cascading Failures In a nutshell — Do not hammer a service with additional requests which is already down. Please give the service time to recover.
Avoid Single Points of Failure
Handle Failures Gracefully and Allow for Fast Degradation
What Are the Design Patterns to Ensure Service Resiliency?

Circuit Breaker Pattern, Retry Design Pattern, Timeout Design Pattern

Database per Service Or Shared Db

https://medium.com/design-microservices-architecture-with-patterns

https://medium.com/design-microservices-architecture-with-patterns/service-registry-pattern-75f9c4e50d09

multi-tenant-architecture

https://www.clickittech.com/saas/multi-tenant-architecture/

example :

gitlab.mycom1.com
mycom1.awsapps.com

Based on organization providing different url where it seems like it single dedicated system, but underlaying resources are shared among organization there, It could be possible only compute resource only shared with different db per org

Single-tenant-Multy-tenant

12-factor-app

The twelve-factor app is a methodology for building software-as-a-service apps that:

Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices.

Useful tools and technologies:

1. Reverse proxy :

A proxy server is a go‑between or intermediary server that forwards requests for content from multiple clients to different servers across the Internet. A reverse proxy server is a type of proxy server that typically sits behind the firewall in a private network and directs client requests to the appropriate backend server. A reverse proxy provides an additional level of abstraction and control to ensure the smooth flow of network traffic between clients and servers.

Common uses for a reverse proxy server include:

- Load balancing– A reverse proxy server can act as a “traffic cop,” sitting in front of your backend servers and distributing client requests across a group of servers in a manner that maximizes speed and capacity utilization while ensuring no one server is overloaded, which can degrade performance. If a server goes down, the load balancer redirects traffic to the remaining online servers.

- Web acceleration – Reverse proxies can compress inbound and outbound data, as well as cache commonly requested content, both of which speed up the flow of traffic between clients and servers. They can also perform additional tasks such as SSL encryption to take load off of your web servers, thereby boosting their performance.

- Security and anonymity – By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. It also ensures that multiple servers can be accessed from a single record locator or URL regardless of the structure of your local area network.

Nginx :

https://www.nginx.com/blog/deploying-nginx-nginx-plus-docker-2/
Architecting Zero Trust Security for Kubernetes Apps with NGINX https://www.nginx.com/blog/architecting-zero-trust-security-for-kubernetes-apps-with-nginx/
1. Consistent-hashing

https://medium.com/must-know-computer-science/system-design-consistent-hashing-f66fa9b75f3f

1. Storage

https://medium.com/must-know-computer-science/system-desing-storage-d8ef4a8d952c

1. Database sharding

https://www.digitalocean.com/community/tutorials/understanding-database-sharding

1. Caching

https://massivetechinterview.blogspot.com/2017/04/system-design-cache.html

https://medium.com/must-know-computer-science/system-design-caching-acbd1b02ca01

1. CAP

https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html [must read]

https://codahale.com/you-cant-sacrifice-partition-tolerance/

Degrees of CAP theorem, use cases video

cap

Introduction : Eric Brewer, states that any distributed data store can provide only two of the following three guarantees:

Consistency : Every read receives the most recent write or an error.
Availability : Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
Partition tolerance : The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

When a network partition failure happens, it must be decided whether to

cancel the operation and thus decrease the availability but ensure consistency or to
proceed with the operation and thus provide availability but risk inconsistency.
Example :

ZooKeeper is a CP system with regard to the CAP theorem. This implies that it sacrifices availability in order to achieve consistency and partition tolerance. In other words, if it cannot guarantee correct behavior it will not respond to queries.

GOOD Blogs