Topic 1: Distributed Transactions: =================== Synchronous: 2PC & 3PC Asynchronous: SAGA (Choreography & Orchestration) #LearnWithMe

Topic 15: Even Sourcing Pattern: ================= DBs only store state, it doesn't tell us how it came to that state. Also, we don't know, who deposited money? When? What happened before? How did it become 5000? In event sourcing approach, instead of storing state, you store events. AccountCreated(1000) MoneyDesposited(500) MoneyWithdrawn(200) MoneyDesposited(200) Then a process called HYDRATION, runs these events and give us the final state Uses: ------ -We have complete Audit trail -Debugging Real-world examples: ----------------------- -Banking transactions -Order history in e-ommerce -Trading Systems Question: ----------- 1. So do I have to run, all the events to get a particular final state? -No, after every time period, you will aggregate the events, and store the state in DB. Next time you will start aggregating only from the position that is not present in DB -If any misunderstanding happens, we will re-run the events again and update the state 2. What is the proof that workers read the events and aggregate them in the same order? one worker can consume fast and other worker can consume slow? then the final state stored in DB is wrong. -Usually in Kafka, there is a Consumer Groups & Topic Partition, where a node in a consumer group always get data from one partition. Kafka guarantees ordering only within a partition

Topic 14: Sidecar Pattern: ============ An independent helper service attached to main service -Helps in independent scalability of a function. Some of the functionalities of sidecar -> logging, authentication, configuration, etc. Lifespan: --------- The sidecar and the main application, while separate entities, share the same lifespan in the sidecar pattern architecture. They get created, deployed and destroyed together. In Docker, always try to keep sidecar and main service in same container Use cases: ------------ -Monitoring and Metric collection -Logging -Security and authentication Kubernetes sidecar is Istio

Topic 13: Retry Pattern: ========== Retry pattern is used because most of the request failures are Transient or non-deterministic and will be recovered in few seconds. What we do in retry pattern is we will send the request again after few seconds Retry pattern should only kick in temporary errors like network timeouts, 5xx server errors, database deadlocks. Avoid for input validation failures (400), or authentication errors (HTTP 401) are permanent errors for that request. Architecture: -------------- -Retry Policy & Parameters: How and when to retry -Backoff Strategy: Constant delay, exponential delay -Jitter (Randomization): To prevent "THUNDERING HERD", if all clients retry same time, this will cause failure gain, so we need randomization -Circuit Breaker Integration -Idempotency and Side effects Use cases: ======== -Database operations -Microservice architecture

Topic 12: Backpressure ========== Backpressure is a mechanism used in distributed systems to control overload when a service is receiving more data than it can process. Where is it used? -APIs: Rate limiting (429 errors) -Golang: Buffered channels -Streaming: Reactive streams, consumer tells I can handle 10, so producer only produces 10, wait till consumer asks more -Microservices: We have thread pool, if it gets filled, we add those requests in queue, so new requests wait, latency increases. Once queue is full, requests drop -Kafka: Bounded producer buffer Pull-based consumption broker persistence

Topic 11: What if DB connections maxed out and requests are failing? - Enable rate-limiting & Backpressure - Use caching for hot reads - Divert read operations to read-replicas - Use asynchronous mechanisms (queues) for non-critical writes NOTE: Here horizontal scaling of servers don't work, because this is not server issue, it is DB issue Source: Learned from @SidJain_80 's tweet

Topic 10: Bulkhead Pattern: ============= The Bulkhead pattern directly address the problem of failure propagation. By isolating system components, it prevents a failure in one component from impacting the others. By doing this, it reduces the risk of a cascading failure Bulkhead = restricting resource utilization so that one failure or workload cannot consume all shared resources. It restricts: Threads, connection Pools, CPU, memory, Worker processes, Queues, Rate limits Architecture: -------------- The architecture of Bulkhead patterns is around ISOLATION and RESOURCES. To implement this we have to create isolation units within our systems and allocate resource to these units. It could be restricting processes, threads, cpu time, memory or separate services, network bandwidth, db connections. Every bulkhead operates independently. Each bulkhead gets dedicated share of these resources. Easy Understanding: ---------------------- Think of Kubernetes Node, it can host multiple Pods. Pod-A, Pod-B, Pod-C. Now if Pod-A starts consuming all resources, Pod-B and Pod-C gets affected. So in Kubernetes, we have option to restrict resources to pod A pod itself is not the Bulkhead pattern, but pods combined with resource limits (CPU, memory, quotas) are a common way to implement the Bulkhead pattern in Kubernetes. Circuit Breaker vs Bulkhead pattern: -------------------------------------- Circuit breaker protects you from bad dependencies; bulkhead protects you from resource exhaustion Drawbacks: ------------ -The allocated resources may not be fully utilized by a resource, so try using dynamic approach when needed FAQ: ----- 1. If we run one pod on one node, don't we need Bulkhead pattern? - We still need bulkhead pattern to manage resources within node. Take an example, your order service makes call to payment service & Notification service. We should have a separate threadpool for calling both these services, because if notification services delayed responses and holds all threads.... then we cannot make calls to payment service

Topic 9: Circuit Breaker Pattern: ================= If a service becomes unresponsive and the application keeps calling it, the results can be disastrous, requests pile up, threads hang and eventually the failure cascades into a wider outage. A software circuit breaker "trips" to stop calls to a failing service. Fail Fast and prevent repeated futile attempts Architecture: -------------- 1. Closed: Normal operations, if no.of failures exceeds a configured failure threshold, the breaker transitions to open state. 2. Open: Circuit is "tripped". Calls are blocked immediately 3. Half-Open: Trail mode. In this state, it will allow a limited number of test requests to the actual service. State Transitions: - Closed -> Open, when failures exceed the threshold - Open -> Half-Open, after the timeout elapses - Half-Open -> Open, if the test call fails - Half-Open -> Closed, if trail requests succeed Best Practices: ---------------- 1. Fallbacks: When circuit breaker opens, you can send cached data, default value. 2. Monitoring & Alerts: When circuit opens, better sending an alert Use Cases: ------------ 1. Microservices 2. External API integration 3. Database Access #LearnWithMe

Topic 7: Checksum: ========= Input Data -> Cryptographic hash functions like MD5, SHA-1, SHA-256, SHA-512 -> fixed size string is called checksum Checksum is used for checking data corruption during data transfer/upload Can be done both client-side and server-side Advantages of client-side checksum: =========================== -Detect data corruption during transmission -Resumable downloads (only after checksum match for each chunk, we mark that chunk as uploaded) -Deduplication before upload -Companies that do: Youtube, Google Drive, S3(optional), Dropbox Advantages of server-side checksum: ============================ -Verify storage integrity (to check disk corruption, large systems periodically check files) -Deduplication inside storage -Replication verification -Companies that do: Local file backup software, Dropbox, Google Drive, Youtube

Topic 6: Backends For Frontends pattern (BFFs): ============================= In large organizations (Instagram, Facebook), their app/website can be opened in laptops, phones, TVs, smartwatches. Making all these devices use same backend will be inefficient. So, each device, will call its own backend, which is optimized for their use, this is known as Backends for Frontends pattern. REMEMBER: ========= BFFs are not different microservices, they are services that sit in front of microservices, calls from one service. -Mobile requests go to Mobile BFF, Web request goes to Web BFF. But these BFFs call same microservices. -They just filter, transform and reduce network calls Advantages: ------------- -BFF responses are unique to each device, so responses are optimized - Frontends don't need to deal with multiple microservices. They have a single backend that aggregates and processes the needed data. -Enhanced user experience -Easier maintenance, loose coupling between devices and encourages independence -Different security for different devices -Agility, teams can work independently on their specific BFF -Scalability -Facilitates A/B testing: You can test a specific feature on particular type of client (example: Mobile app) -Reduces bandwidth based on device. Prevents over-fetching data. Problems: ======= - Code duplication - Increased maintenance - Adds additional network hop, so network latency increases -Caching challenges #LearnWithMe

Topic 5: API Gateway Pattern: =============== In a microservice, we might be having different services doing different things, having a single point of entry for external consumers to access these various services is known as API Gateway pattern. It makes easier to manage, secure our services and provide unified interface to external world -It hides the complexity from the clients Functions of API Gateway: ---------------------------- Routing, Authorization, Rate limiting, Load Balancing, Caching, Monitoring, Logging, Transformation, Service Discovery, Circuit breaker, version management Advantages of Using API Gateway pattern: --------------------------------------------- 1. Reduces complexity of interactions: API gateway simplifies the communication between different services. 2. Consistency API Calls: Different services use different data formats to interact. API gateways translate calls & data formats 3. Security: Central place to handle authentication and authorization. 4. Load Balancing 5. Caching: Can cache responses from service and improve performance 6. Single point for monitoring, analytics and logging 7. Version Management: Can route requests to different versions of a service based on client request 8. API gateway can act as request aggregator, user don't have to send multiple requests to get some information, API gateway does call different services, collects info and send back the full information. -Here client is making only one call to API gateway, but API gateway is making multiple calls & reducing user's effort -Example: On Instagram, user sends API request to get feed, API Gate way sends request to Notification service and feed service, aggregates response and sends back to user 9. Different clients might need different types of information, API gateway takes care of that (for example: Request made from phone, cli, laptop & TV might get data in different formats) Problems of API Gateway pattern: ------------------------------------ 1. Single point of failure: Go for redundancy 2. Bottleneck: All requests go through the gateway, so scale horizontally. 3. Complexity: Gateway will do many things, so split the functionalities into multiple gateways 4. Security: If gateway is compromised, everything is done and dusted

Topic 4: Strangler Fig Pattern: ================ -Monolith (legacy system) is slowly replaced with a microservice -Firstly, we will remove redundancy in monolith and make components loosely coupled -Then we introduce abstraction -Now, we try to create new microservice one by one for each functionality of monolith -We will introduce a Facade interface/router/proxy layer (IMPORTANT), to divert the traffic to new microservice -Facade interface is the backbone of Strangler fig pattern Things to keep in mind while introducing Strangler fig pattern: ---------------------------------------- 1. Proxy layer: Gatekeeper that knows which service was now available in microservice & which is still present in monolith -Use features flags to turn on/off new functionalities -User segmentation: route users in phases for A/B testing -API version: route request based on version headers 2. Data consistency: New microservice should sync data with legacy system, either through replication. -Replication can be done by even-driven approach 3. State management: If you are doing phased roll out, keep in mind that we have to do to state sharing between old and new systems/ -Like shared caches, etc. 4. Rollback strategy: We should have a prepared strategy to rollback to old system -Example, use feature toggles or dynamic routing to easily switch between systems. 5. Testing: Testing should be done properly -Contract Testing: Are all our new features obeying expected behaviour -E2E testing -Performance Testing: 6. Zero-Downtime Migration: -Use approaches like blue-green or canary deployment so user don't face any issue 7. Data Transformation: Our new service might be using different database model, so we should make sure to add a middleware to do data transformation 8. Security Consideration: Since 2 different services are now talking, we should make sure to check potential security vulnerabilities -Also use security practices like API throttling, service-to-service authentication (mTLS), and regular vulnerability scanning.

Topic 3: 1. Blue-Green Deployment: ================== -Maintains two identical environments: Blue(current) and Green(new). Switch all traffic at once. -100% switch in one step -All users get the new version immediately 2. Canary Deployment: =============== -Release the new version to a small percentage of users first, then gradually increase traffic -Only a subset of users see the new version initially -When you want to minimize risk and validate changes with real users. #LearnWithMe