Add DevOps roadmap as a next step

content/roadmaps/101-backend/content-paths.json

@@ -48,22 +48,27 @@
   "nosql-databases:column-databases": "/roadmaps/101-backend/content/107-nosql-databases/101-column-databases.md",
   "nosql-databases:timeseries-databases": "/roadmaps/101-backend/content/107-nosql-databases/102-timeseries-databases.md",
   "nosql-databases:realtime-databases": "/roadmaps/101-backend/content/107-nosql-databases/103-realtime-databases.md",
+  "nosql-databases:key-value-databases": "/roadmaps/101-backend/content/107-nosql-databases/104-key-value-databases.md",
   "more-about-databases": "/roadmaps/101-backend/content/108-more-about-databases/readme.md",
   "more-about-databases:orms": "/roadmaps/101-backend/content/108-more-about-databases/100-orms.md",
   "more-about-databases:acid": "/roadmaps/101-backend/content/108-more-about-databases/101-acid.md",
   "more-about-databases:transactions": "/roadmaps/101-backend/content/108-more-about-databases/102-transactions.md",
   "more-about-databases:n-plus-one-problem": "/roadmaps/101-backend/content/108-more-about-databases/103-n-plus-one-problem.md",
   "more-about-databases:database-normalization": "/roadmaps/101-backend/content/108-more-about-databases/104-database-normalization.md",
-  "more-about-databases:database-indexes": "/roadmaps/101-backend/content/108-more-about-databases/105-database-indexes.md",
-  "more-about-databases:data-replication": "/roadmaps/101-backend/content/108-more-about-databases/106-data-replication.md",
-  "more-about-databases:sharding-strategies": "/roadmaps/101-backend/content/108-more-about-databases/107-sharding-strategies.md",
-  "more-about-databases:cap-theorem": "/roadmaps/101-backend/content/108-more-about-databases/108-cap-theorem.md",
+  "more-about-databases:failure-modes": "/roadmaps/101-backend/content/108-more-about-databases/105-failure-modes.md",
+  "more-about-databases:profiling-performance": "/roadmaps/101-backend/content/108-more-about-databases/106-profiling-performance.md",
+  "scaling-databases": "/roadmaps/101-backend/content/109-scaling-databases/readme.md",
+  "scaling-databases:database-indexes": "/roadmaps/101-backend/content/109-scaling-databases/100-database-indexes.md",
+  "scaling-databases:data-replication": "/roadmaps/101-backend/content/109-scaling-databases/101-data-replication.md",
+  "scaling-databases:sharding-strategies": "/roadmaps/101-backend/content/109-scaling-databases/102-sharding-strategies.md",
+  "scaling-databases:cap-theorem": "/roadmaps/101-backend/content/109-scaling-databases/103-cap-theorem.md",
   "apis": "/roadmaps/101-backend/content/109-apis/readme.md",
   "apis:rest": "/roadmaps/101-backend/content/109-apis/100-rest.md",
   "apis:json-apis": "/roadmaps/101-backend/content/109-apis/101-json-apis.md",
   "apis:soap": "/roadmaps/101-backend/content/109-apis/102-soap.md",
   "apis:grpc": "/roadmaps/101-backend/content/109-apis/103-grpc.md",
   "apis:hateoas": "/roadmaps/101-backend/content/109-apis/104-hateoas.md",
+  "apis:graphql": "/roadmaps/101-backend/content/109-apis/106-graphql.md",
   "apis:open-api-spec": "/roadmaps/101-backend/content/109-apis/105-open-api-spec.md",
   "apis:authentication": "/roadmaps/101-backend/content/109-apis/106-authentication/readme.md",
   "apis:authentication:cookie-based": "/roadmaps/101-backend/content/109-apis/106-authentication/100-cookie-based.md",
@@ -98,16 +103,15 @@
   "design-and-development-principles:gof-design-patterns": "/roadmaps/101-backend/content/114-design-and-development-principles/100-gof-design-patterns.md",
   "design-and-development-principles:domain-driven-design": "/roadmaps/101-backend/content/114-design-and-development-principles/101-domain-driven-design.md",
   "design-and-development-principles:test-driven-development": "/roadmaps/101-backend/content/114-design-and-development-principles/102-test-driven-development.md",
-  "design-and-development-principles:solid": "/roadmaps/101-backend/content/114-design-and-development-principles/103-solid.md",
-  "design-and-development-principles:kiss": "/roadmaps/101-backend/content/114-design-and-development-principles/104-kiss.md",
-  "design-and-development-principles:yagni": "/roadmaps/101-backend/content/114-design-and-development-principles/105-yagni.md",
-  "design-and-development-principles:dry": "/roadmaps/101-backend/content/114-design-and-development-principles/106-dry.md",
+  "design-and-development-principles:cqrs": "/roadmaps/101-backend/content/114-design-and-development-principles/103-cqrs.md",
+  "design-and-development-principles:event-sourcing": "/roadmaps/101-backend/content/114-design-and-development-principles/104-event-sourcing.md",
   "architectural-patterns": "/roadmaps/101-backend/content/115-architectural-patterns/readme.md",
   "architectural-patterns:monolithic-apps": "/roadmaps/101-backend/content/115-architectural-patterns/100-monolithic-apps.md",
   "architectural-patterns:microservices": "/roadmaps/101-backend/content/115-architectural-patterns/101-microservices.md",
   "architectural-patterns:soa": "/roadmaps/101-backend/content/115-architectural-patterns/102-soa.md",
-  "architectural-patterns:cqrs": "/roadmaps/101-backend/content/115-architectural-patterns/103-cqrs.md",
   "architectural-patterns:serverless": "/roadmaps/101-backend/content/115-architectural-patterns/104-serverless.md",
+  "architectural-patterns:service-mesh": "/roadmaps/101-backend/content/115-architectural-patterns/105-service-mesh.md",
+  "architectural-patterns:twelve-factor-apps": "/roadmaps/101-backend/content/115-architectural-patterns/106-twelve-factor-apps.md",
   "search-engines": "/roadmaps/101-backend/content/116-search-engines/readme.md",
   "search-engines:elasticsearch": "/roadmaps/101-backend/content/116-search-engines/100-elasticsearch.md",
   "search-engines:solr": "/roadmaps/101-backend/content/116-search-engines/101-solr.md",
@@ -116,7 +120,7 @@
   "message-brokers:kafka": "/roadmaps/101-backend/content/117-message-brokers/101-kafka.md",
   "containerization": "/roadmaps/101-backend/content/118-containerization/readme.md",
   "containerization:docker": "/roadmaps/101-backend/content/118-containerization/100-docker.md",
-  "containerization:rkt": "/roadmaps/101-backend/content/118-containerization/101-rkt.md",
+  "containerization:kubernetes": "/roadmaps/101-backend/content/118-containerization/103-kubernetes.md",
   "containerization:lxc": "/roadmaps/101-backend/content/118-containerization/102-lxc.md",
   "graphql": "/roadmaps/101-backend/content/119-graphql/readme.md",
   "graphql:apollo": "/roadmaps/101-backend/content/119-graphql/100-apollo.md",
@@ -124,13 +128,19 @@
   "graph-databases": "/roadmaps/101-backend/content/120-graph-databases/readme.md",
   "graph-databases:neo4j": "/roadmaps/101-backend/content/120-graph-databases/100-neo4j.md",
   "web-sockets": "/roadmaps/101-backend/content/121-web-sockets.md",
+  "server-sent-events": "/roadmaps/101-backend/content/122-server-sent-events.md",
   "web-servers": "/roadmaps/101-backend/content/122-web-servers/readme.md",
   "web-servers:nginx": "/roadmaps/101-backend/content/122-web-servers/100-nginx.md",
   "web-servers:apache": "/roadmaps/101-backend/content/122-web-servers/101-apache.md",
   "web-servers:caddy": "/roadmaps/101-backend/content/122-web-servers/102-caddy.md",
   "web-servers:ms-iis": "/roadmaps/101-backend/content/122-web-servers/103-ms-iis.md",
   "scalability": "/roadmaps/101-backend/content/123-scalability/readme.md",
-  "scalability:mitigation-strategies": "/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies.md",
+  "scalability:mitigation-strategies": "/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/readme.md",
+  "scalability:mitigation-strategies:graceful-degradation": "/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/100-graceful-degradation.md",
+  "scalability:mitigation-strategies:throttling": "/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/101-throttling.md",
+  "scalability:mitigation-strategies:backpressure": "/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/102-backpressure.md",
+  "scalability:mitigation-strategies:loadshifting": "/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/103-loadshifting.md",
+  "scalability:mitigation-strategies:circuit-breaker": "/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/104-circuit-breaker.md",
   "scalability:instrumentation-monitoring-telemetry": "/roadmaps/101-backend/content/123-scalability/101-instrumentation-monitoring-telemetry.md",
   "scalability:migration-strategies": "/roadmaps/101-backend/content/123-scalability/102-migration-strategies.md",
   "scalability:horizontal-vertical-scaling": "/roadmaps/101-backend/content/123-scalability/103-horizontal-vertical-scaling.md",

content/roadmaps/101-backend/content/103-learn-a-language/103-csharp.md

@@ -1,4 +1,4 @@
-# Csharp
+# C#
 C# (pronounced "C sharp") is a general purpose programming language made by Microsoft. It is used to perform different tasks and can be used to create web apps, games, mobile apps, etc.
 
 <ResourceGroupTitle>Free Content</ResourceGroupTitle>

content/roadmaps/101-backend/content/103-learn-a-language/105-javascript.md

@@ -6,8 +6,9 @@
 
 # JavaScript
 
-JavaScript, often abbreviated JS, is a programming language that is one of the core technologies of the World Wide Web, alongside HTML and CSS. It lets us add interactivity to pages e.g. you might have seen sliders, alerts, click interactions, and popups etc on different websites -- all of that is built using JavaScript. Apart from being used in the browser, it is also used in other non-browser environments as well such as Node.js for writing server-side code in JavaScript, Electron for writing desktop applications, React Native for mobile applications and so on.
+Apart from being used in the browser, JavaScript is also used in backend e.g. using [Node.js](https://nodejs.org/) or [Deno](https://deno.land/) for writing server-side code in JavaScript.
 
+If you pick up JavaScript for the Backend, my personal recommendation would be to learn [JavaScript](/javascript) and then go with [Node.js](/nodejs) as it is the most popular and widely used option. Also, I would recommend learning TypeScript later on as you continue with your backend development Journey; it's a superset of JavaScript and is used in many projects. 
 
 <ResourceGroupTitle>Free Content</ResourceGroupTitle>
 

content/roadmaps/101-backend/content/103-learn-a-language/readme.md

@@ -3,3 +3,5 @@
 Even if you’re a beginner the least you would have known is that Web Development is majorly classified into two facets: Frontend Development and Backend Development. And obviously, they both have their respective set of tools and technologies. For instance, when we talk about Frontend Development, there always comes 3 names first and foremost – HTML, CSS, and JavaScript.  
 
 In the same way, when it comes to Backend Web Development – we primarily require a backend (or you can say server-side) programming language to make the website function along with various other tools & technologies such as databases, frameworks, web servers, etc.
+
+Pick a language from the given list and make sure to learn its quirks, core details about its runtime e.g. concurrency, memory model etc.

content/roadmaps/101-backend/content/107-nosql-databases/104-key-value-databases.md

@@ -0,0 +1,10 @@
+# Key-Value Databases
+
+A key-value database (KV database) is a type of database that stores data as a collection of key-value pairs. In a KV database, each piece of data is identified by a unique key, and the value is the data associated with that key.
+
+KV databases are designed for fast and efficient storage and retrieval of data, and they are often used in applications that require high performance and low latency. They are particularly well-suited for storing large amounts of unstructured data, such as log data and user profiles.
+
+Some popular KV databases include Redis, Memcached, and LevelDB. These databases are often used in combination with other types of databases, such as relational databases or document databases, to provide a complete and scalable data storage solution.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://en.wikipedia.org/wiki/Key-value_database'>Key-Value Databases - Wikipedia</BadgeLink>

content/roadmaps/101-backend/content/108-more-about-databases/105-failure-modes.md

@@ -0,0 +1,14 @@
+# Failure Modes
+
+There are several different failure modes that can occur in a database, including:
+
+* Read contention: This occurs when multiple clients or processes are trying to read data from the same location in the database at the same time, which can lead to delays or errors.
+* Write contention: This occurs when multiple clients or processes are trying to write data to the same location in the database at the same time, which can lead to delays or errors.
+* Thundering herd: This occurs when a large number of clients or processes try to access the same resource simultaneously, which can lead to resource exhaustion and reduced performance.
+* Cascade: This occurs when a failure in one part of the database system causes a chain reaction that leads to failures in other parts of the system.
+* Deadlock: This occurs when two or more transactions are waiting for each other to release a lock on a resource, leading to a standstill.
+* Corruption: This occurs when data in the database becomes corrupted, which can lead to errors or unexpected results when reading or writing to the database.
+* Hardware failure: This occurs when hardware components, such as disk drives or memory, fail, which can lead to data loss or corruption.
+* Software failure: This occurs when software components, such as the database management system or application, fail, which can lead to errors or unexpected results.
+* Network failure: This occurs when the network connection between the database and the client is lost, which can lead to errors or timeouts when trying to access the database.
+* Denial of service (DoS) attack: This occurs when a malicious actor attempts to overwhelm the database with requests, leading to resource exhaustion and reduced performance.

content/roadmaps/101-backend/content/108-more-about-databases/106-profiling-performance.md

@@ -0,0 +1,11 @@
+# Profiling Performance
+
+There are several ways to profile the performance of a database:
+
+* Monitor system performance: You can use tools like the Windows Task Manager or the Unix/Linux top command to monitor the performance of your database server. These tools allow you to see the overall CPU, memory, and disk usage of the system, which can help identify any resource bottlenecks.
+* Use database-specific tools: Most database management systems (DBMSs) have their own tools for monitoring performance. For example, Microsoft SQL Server has the SQL Server Management Studio (SSMS) and the sys.dm_os_wait_stats dynamic management view, while Oracle has the Oracle Enterprise Manager and the v$waitstat view. These tools allow you to see specific performance metrics, such as the amount of time spent waiting on locks or the number of physical reads and writes.
+* Use third-party tools: There are also several third-party tools that can help you profile the performance of a database. Some examples include SolarWinds Database Performance Analyzer, Quest Software Foglight, and Redgate SQL Monitor. These tools often provide more in-depth performance analysis and can help you identify specific issues or bottlenecks.
+* Analyze slow queries: If you have specific queries that are running slowly, you can use tools like EXPLAIN PLAN or SHOW PLAN in MySQL or SQL Server to see the execution plan for the query and identify any potential issues. You can also use tools like the MySQL slow query log or the SQL Server Profiler to capture slow queries and analyze them further.
+* Monitor application performance: If you are experiencing performance issues with a specific application that is using the database, you can use tools like Application Insights or New Relic to monitor the performance of the application and identify any issues that may be related to the database.
+
+Have a look at the documentation for the database that you are using.

content/roadmaps/101-backend/content/109-apis/106-graphql.md

@@ -0,0 +1,12 @@
+# GraphQL
+
+GraphQL is a query language and runtime system for APIs (application programming interfaces). It is designed to provide a flexible and efficient way for clients to request data from servers, and it is often used as an alternative to REST (representational state transfer) APIs.
+
+One of the main features of GraphQL is its ability to specify exactly the data that is needed, rather than receiving a fixed set of data from an endpoint. This allows clients to request only the data that they need, and it reduces the amount of data that needs to be transferred over the network.
+
+GraphQL also provides a way to define the structure of the data that is returned from the server, allowing clients to request data in a predictable and flexible way. This makes it easier to build and maintain client applications that depend on data from the server.
+
+GraphQL is widely used in modern web and mobile applications, and it is supported by a large and active developer community.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='blue' badgeText='Official Website' href='https://graphql.org/'>GraphQL Official Website</BadgeLink>

content/roadmaps/101-backend/content/109-scaling-databases/readme.md

@@ -0,0 +1,7 @@
+# Databases
+
+A database is a collection of useful data of one or more related organizations structured in a way to make data an asset to the organization. A database management system is a software designed to assist in maintaining and extracting large collections of data in a timely fashion.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.oracle.com/database/what-is-database/'>Oracle: What is a Database?</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.prisma.io/dataguide/intro/what-are-databases'>Prisma.io: What are Databases?</BadgeLink>

content/roadmaps/101-backend/content/114-design-and-development-principles/103-cqrs.md

@@ -1,4 +1,4 @@
-# CQRS and Event Sourcing
+# CQRS
 
 CQRS, or command query responsibility segregation, defines an architectural pattern where the main focus is to separate the approach of reading and writing operations for a data store. CQRS can also be used along with Event Sourcing pattern in order to persist application state as an ordered of sequence events, making it possible to restore data to any point in time.
 

content/roadmaps/101-backend/content/114-design-and-development-principles/103-solid.md

@@ -1,15 +0,0 @@
-# SOLID
-
-SOLID is a set of principles applied to object-oriented design (OOD) to create maintainable, understandable, and flexible code, while avoiding code smells and defects. The principles are:
-
-- Single Responsibility
-- Open/Closed
-- Liskov Substitution
-- Interface Segregation
-- Dependency Inversion
-
-<ResourceGroupTitle>Free Content</ResourceGroupTitle>
-<BadgeLink colorScheme='blue' badgeText='Official Docs' href='https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf'>Design Principles and
-Design Patterns</BadgeLink>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.baeldung.com/solid-principles'>SOLID Principles</BadgeLink>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design'>SOLID: The First 5 Principles of Object Oriented Design</BadgeLink>

content/roadmaps/101-backend/content/114-design-and-development-principles/104-event-sourcing.md

@@ -0,0 +1,10 @@
+# Event Sourcing
+
+Event sourcing is a design pattern in which the state of a system is represented as a sequence of events that have occurred over time. In an event-sourced system, changes to the state of the system are recorded as events and stored in an event store. The current state of the system is derived by replaying the events from the event store.
+
+One of the main benefits of event sourcing is that it provides a clear and auditable history of all the changes that have occurred in the system. This can be useful for debugging and for tracking the evolution of the system over time.
+
+Event sourcing is often used in conjunction with other patterns, such as Command Query Responsibility Segregation (CQRS) and domain-driven design, to build scalable and responsive systems with complex business logic. It is also useful for building systems that need to support undo/redo functionality or that need to integrate with external systems.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://martinfowler.com/eaaDev/EventSourcing.html'>Event Sourcing - Martin Fowler</BadgeLink>

content/roadmaps/101-backend/content/114-design-and-development-principles/104-kiss.md

@@ -1,7 +0,0 @@
-# KISS
-
-Keep It Simple, Stupid (KISS) is a software design principle that states avoiding needless complexity is the best way to build software that is easier to maintain, understand, and contains fewer defects. A simple product that does a single thing well is better than a complex product that does many things poorly.
-
-<ResourceGroupTitle>Free Content</ResourceGroupTitle>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://deviq.com/principles/keep-it-simple'>Keep It Simple</BadgeLink>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.interaction-design.org/literature/topics/keep-it-simple-stupid'>Keep It Simple, Stupid (Kiss)</BadgeLink>

content/roadmaps/101-backend/content/114-design-and-development-principles/105-yagni.md

@@ -1,7 +0,0 @@
-# YAGNI
-
-You Aren't Going to Need It (YAGNI) is a software design principle from the Extreme Programming (XP) framework that states when developing software, functionality or features should not be added until they are necessary. Within agile software development in general, requirements are always open to change; any extra functionality may end up being wasted time and resources.
-
-<ResourceGroupTitle>Free Content</ResourceGroupTitle>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://martinfowler.com/bliki/Yagni.html'>Yagni</BadgeLink>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://deviq.com/principles/yagni'>YAGNI</BadgeLink>

content/roadmaps/101-backend/content/114-design-and-development-principles/106-dry.md

@@ -1,7 +0,0 @@
-# DRY
-
-Don't Repeat Yourself (DRY) is a software design principle which encourages developers to not repeat software patterns or code. DRY encourages code reusability, often in the form of methods, functions, or subroutines. When DRY is implemented successfully, developers are able to make one change to update many related elements while avoiding making changes to unrelated elements.
-
-<ResourceGroupTitle>Free Content</ResourceGroupTitle>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://dzone.com/articles/software-design-principles-dry-and-kiss'>Software Design Principles DRY and KISS</BadgeLink>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.1001745#s5'>Best Practices for Scientific Computing</BadgeLink>

content/roadmaps/101-backend/content/115-architectural-patterns/105-service-mesh.md

@@ -0,0 +1,13 @@
+# Service Mesh
+
+A service mesh is a network of microservices that are connected using a mesh of interconnected, intelligent proxies. It is used to manage and secure communication between microservices, and it provides features such as load balancing, service discovery, and observability.
+
+In a service mesh, each microservice is typically represented by an instance of a lightweight, transparent proxy called an "envoy." The envoys handle the communication between microservices and provide features such as load balancing, routing, and security.
+
+Service meshes are typically implemented using a sidecar pattern, in which the envoys are deployed alongside the microservices they are responsible for. This allows the service mesh to be decoupled from the microservices and makes it easier to manage and update.
+
+Service meshes are commonly used in cloud-native architectures and are often managed using a control plane, which is responsible for configuring and managing the envoys. Some popular service mesh implementations include Istio and Linkerd.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.nginx.com/blog/what-is-a-service-mesh/'>What is a Service Mesh?</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.cncf.io/blog/2018/05/02/service-mesh-explained/'>Service Mesh Explained - Cloud Native Computing Foundation (CNCF)</BadgeLink>

content/roadmaps/101-backend/content/115-architectural-patterns/106-twelve-factor-apps.md

@@ -0,0 +1,23 @@
+# Twelve-Factor Apps
+
+The Twelve-Factor App is a methodology for building scalable and maintainable software-as-a-service (SaaS) applications. It is based on a set of best practices that were identified by the authors of the methodology as being essential for building modern, cloud-native applications.
+
+The Twelve-Factor App methodology consists of the following principles:
+
+* Codebase: There should be a single codebase for the application, with multiple deployments.
+* Dependencies: The application should explicitly declare and isolate its dependencies.
+* Config: The application should store configuration in the environment.
+* Backing services: The application should treat backing services as attached resources.
+* Build, release, run: The application should be built, released, and run as an isolated unit.
+* Processes: The application should be executed as one or more stateless processes.
+* Port binding: The application should expose its services through port binding.
+* Concurrency: The application should scale out by adding more processes, not by adding threads.
+* Disposability: The application should be designed to start and stop quickly.
+* Dev/prod parity: The development, staging, and production environments should be as similar as possible.
+* Logs: The application should treat logs as event streams.
+* Admin processes: The application should run admin/maintenance tasks as one-off processes.
+
+The Twelve-Factor App methodology is widely adopted by developers of SaaS applications, and it is seen as a best practice for building cloud-native applications that are scalable, maintainable, and easy to deploy.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://12factor.net/'>The Twelve-Factor App</BadgeLink>

content/roadmaps/101-backend/content/118-containerization/101-rkt.md

@@ -1,13 +0,0 @@
-# RKT
-
-RKT(pronounced like a "rocket") is an application container engine developed for modern production cloud-native environments. It features a pod-native approach, a pluggable execution environment, and a well-defined surface area that makes it ideal for integration with other systems.
-
-
-RKT project was ended in 2018.
-
-<ResourceGroupTitle>Free Content</ResourceGroupTitle>
-<BadgeLink colorScheme='blue' badgeText='Official Website' href='https://rocket.readthedocs.io/en/latest/Documentation/trying-out-rkt/'>RKT Documentation</BadgeLink>
-<BadgeLink colorScheme='yellow' badgeText='Read' href='https://www.redhat.com/en/topics/containers/what-is-rkt'>What is RKT?</BadgeLink>
-<BadgeLink colorScheme='green' badgeText='Github Repo' href='https://github.com/rkt/rkt'>What is RKT?</BadgeLink>
-<BadgeLink badgeText='Watch' href='https://youtu.be/JgUEXKTSVXw'>Introduction to RKT</BadgeLink>
-<BadgeLink badgeText='Watch' href='https://youtu.be/mRlQC6s8IwM'>The RKT Container Runtime - Explanation & Demonstration</BadgeLink>

content/roadmaps/101-backend/content/118-containerization/103-kubernetes.md

@@ -0,0 +1,12 @@
+# Kubernetes
+
+Kubernetes is an [open source](https://github.com/kubernetes/kubernetes) container management platform, and the dominant product in this space.  Using Kubernetes, teams can deploy images across multiple underlying hosts, defining their desired availability, deployment logic, and scaling logic in YAML.  Kubernetes evolved from Borg, an internal Google platform used to provision and allocate compute resources.  (similar to the Autopilot and Aquaman systems of Microsoft Azure)
+
+The popularity of Kubernetes has made it an increasingly important skill for the DevOps Engineer and has triggered the creation of Platform teams across the industry.  These Platform engineering teams often exist with the sole purpose of making Kubernetes approachable and usable for their product development colleagues.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='blue' badgeText='Official Website' href='https://kubernetes.io/'>Kubernetes Website</BadgeLink>
+<BadgeLink colorScheme='blue' badgeText='Documentation' href='https://kubernetes.io/docs/home/'>Kubernetes Documentation</BadgeLink>
+<BadgeLink badgeText='Watch' href='https://www.youtube.com/watch?v=s_o8dwzRlu4'>Kubernetes Crash Course for Absolute Beginners</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://thenewstack.io/primer-how-kubernetes-came-to-be-what-it-is-and-why-you-should-care/'>Primer: How Kubernetes Came to Be, What It Is, and Why You Should Care</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://thenewstack.io/kubernetes-an-overview/'>Kubernetes: An Overview</BadgeLink>

content/roadmaps/101-backend/content/122-server-sent-events.md

@@ -0,0 +1,10 @@
+# Server Sent Events
+
+Server-Sent Events (SSE) is a technology that allows a web server to push data to a client in real-time. It uses an HTTP connection to send a stream of data from the server to the client, and the client can listen for these events and take action when they are received.
+
+SSE is useful for applications that require real-time updates, such as chat systems, stock tickers, and social media feeds. It is a simple and efficient way to establish a long-lived connection between a client and a server, and it is supported by most modern web browsers.
+
+To use SSE, the client must create an EventSource object and specify the URL of the server-side script that will send the events. The server can then send events by writing them to the response stream with the proper formatting.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events'>Server-Sent Events - MDN</BadgeLink>

content/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/100-graceful-degradation.md

@@ -0,0 +1,11 @@
+# Graceful Degradation
+
+Graceful degradation is a design principle that states that a system should be designed to continue functioning, even if some of its components or features are not available. In the context of web development, graceful degradation refers to the ability of a web page or application to continue functioning, even if the user's browser or device does not support certain features or technologies.
+
+Graceful degradation is often used as an alternative to progressive enhancement, a design principle that states that a system should be designed to take advantage of advanced features and technologies if they are available.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://blog.hubspot.com/website/graceful-degradation'>What is Graceful Degradation & Why Does it Matter?</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://newrelic.com/blog/best-practices/design-software-for-graceful-degradation'>Four Considerations When Designing Systems For Graceful Degradation</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://farfetchtechblog.com/en/blog/post/the-art-of-failure-ii-graceful-degradation/'>The Art of Graceful Degradation</BadgeLink>
+

content/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/101-throttling.md

@@ -0,0 +1,14 @@
+# Throttling
+
+Throttling is a design pattern that is used to limit the rate at which a system or component can be used. It is commonly used in cloud computing environments to prevent overuse of resources, such as compute power, network bandwidth, or storage capacity.
+
+There are several ways to implement throttling in a cloud environment:
+
+* Rate limiting: This involves setting a maximum number of requests that can be made to a system or component within a specified time period.
+* Resource allocation: This involves allocating a fixed amount of resources to a system or component, and then limiting the use of those resources if they are exceeded.
+* Token bucket: This involves using a "bucket" of tokens to represent the available resources, and then allowing a certain number of tokens to be "consumed" by each request. When the bucket is empty, additional requests are denied until more tokens become available.
+
+Throttling is an important aspect of cloud design, as it helps to ensure that resources are used efficiently and that the system remains stable and available. It is often used in conjunction with other design patterns, such as auto-scaling and load balancing, to provide a scalable and resilient cloud environment.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://aws.amazon.com/architecture/well-architected/serverless/patterns/throttling/'>Throttling - AWS Well-Architected Framework</BadgeLink>

content/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/102-backpressure.md

@@ -0,0 +1,14 @@
+# Backpressure
+
+Backpressure is a design pattern that is used to manage the flow of data through a system, particularly in situations where the rate of data production exceeds the rate of data consumption. It is commonly used in cloud computing environments to prevent overloading of resources and to ensure that data is processed in a timely and efficient manner.
+
+There are several ways to implement backpressure in a cloud environment:
+
+* Buffering: This involves storing incoming data in a buffer until it can be processed, allowing the system to continue receiving data even if it is temporarily unable to process it.
+* Batching: This involves grouping incoming data into batches and processing the batches in sequence, rather than processing each piece of data individually.
+* Flow control: This involves using mechanisms such as flow control signals or windowing to regulate the rate at which data is transmitted between systems.
+
+Backpressure is an important aspect of cloud design, as it helps to ensure that data is processed efficiently and that the system remains stable and available. It is often used in conjunction with other design patterns, such as auto-scaling and load balancing, to provide a scalable and resilient cloud environment.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://aws.amazon.com/architecture/well-architected/serverless/patterns/backpressure/'>Backpressure - AWS Well-Architected Framework</BadgeLink>

content/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/103-loadshifting.md

@@ -0,0 +1,14 @@
+# Load Shifting
+
+Load shifting is a design pattern that is used to manage the workload of a system by shifting the load to different components or resources at different times. It is commonly used in cloud computing environments to balance the workload of a system and to optimize the use of resources.
+
+There are several ways to implement load shifting in a cloud environment:
+
+* Scheduling: This involves scheduling the execution of tasks or workloads to occur at specific times or intervals.
+* Load balancing: This involves distributing the workload of a system across multiple resources, such as servers or containers, to ensure that the workload is balanced and that resources are used efficiently.
+* Auto-scaling: This involves automatically adjusting the number of resources that are available to a system based on the workload, allowing the system to scale up or down as needed.
+
+Load shifting is an important aspect of cloud design, as it helps to ensure that resources are used efficiently and that the system remains stable and available. It is often used in conjunction with other design patterns, such as throttling and backpressure, to provide a scalable and resilient cloud environment.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://aws.amazon.com/architecture/well-architected/serverless/patterns/load-shifting/'>Load Shifting - AWS Well-Architected Framework</BadgeLink>

content/roadmaps/101-backend/content/123-scalability/100-mitigation-strategies/104-circuit-breaker.md

@@ -0,0 +1,10 @@
+# Circuit Breaker
+
+The circuit breaker design pattern is a way to protect a system from failures or excessive load by temporarily stopping certain operations if the system is deemed to be in a failed or overloaded state. It is commonly used in cloud computing environments to prevent cascading failures and to improve the resilience and availability of a system.
+
+A circuit breaker consists of three states: closed, open, and half-open. In the closed state, the circuit breaker allows operations to proceed as normal. If the system encounters a failure or becomes overloaded, the circuit breaker moves to the open state, and all subsequent operations are immediately stopped. After a specified period of time, the circuit breaker moves to the half-open state, and a small number of operations are allowed to proceed. If these operations are successful, the circuit breaker moves back to the closed state; if they fail, the circuit breaker moves back to the open state.
+
+The circuit breaker design pattern is useful for protecting a system from failures or excessive load by providing a way to temporarily stop certain operations and allow the system to recover. It is often used in conjunction with other design patterns, such as retries and fallbacks, to provide a more robust and resilient cloud environment.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://aws.amazon.com/architecture/well-architected/serverless/patterns/circuit-breaker/'>Circuit Breaker - AWS Well-Architected Framework</BadgeLink>

content/roadmaps/101-backend/content/123-scalability/102-migration-strategies.md

@@ -1,6 +1,7 @@
 # Migration Strategies
 
-A migration strategy is a plan for moving data from one location to another, and it is an important step in any database migration. A data migration strategy should include a plan for how to move the data and what to do with it once it arrives at the new location.
+Learn how to run database migrations effectively. Especially zero downtime multi-phase schema migrations. Rather than make all changes at once, do smaller incremental changes to allow old code, and new code to worth with the database at the same time, before removing old code, and finally removing the parts of the database schema which is no longer used.
 
 <ResourceGroupTitle>Free Content</ResourceGroupTitle>
-<BadgeLink badgeText='Website' colorScheme="yellow" href='https://theecmconsultant.com/data-migration-strategy'>Migration strategies</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://phauer.com/2015/databases-challenge-continuous-delivery/'>Databases as a Challenge for Continuous Delivery</BadgeLink>
+

content/roadmaps/116-aspnet-core/content/114-microservices/102-kubernetes.md

@@ -1 +1,12 @@
-# Kubernetes
+# Kubernetes
+
+Kubernetes is an [open source](https://github.com/kubernetes/kubernetes) container management platform, and the dominant product in this space.  Using Kubernetes, teams can deploy images across multiple underlying hosts, defining their desired availability, deployment logic, and scaling logic in YAML.  Kubernetes evolved from Borg, an internal Google platform used to provision and allocate compute resources.  (similar to the Autopilot and Aquaman systems of Microsoft Azure)
+
+The popularity of Kubernetes has made it an increasingly important skill for the DevOps Engineer and has triggered the creation of Platform teams across the industry.  These Platform engineering teams often exist with the sole purpose of making Kubernetes approachable and usable for their product development colleagues.
+
+<ResourceGroupTitle>Free Content</ResourceGroupTitle>
+<BadgeLink colorScheme='blue' badgeText='Official Website' href='https://kubernetes.io/'>Kubernetes Website</BadgeLink>
+<BadgeLink colorScheme='blue' badgeText='Documentation' href='https://kubernetes.io/docs/home/'>Kubernetes Documentation</BadgeLink>
+<BadgeLink badgeText='Watch' href='https://www.youtube.com/watch?v=s_o8dwzRlu4'>Kubernetes Crash Course for Absolute Beginners</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://thenewstack.io/primer-how-kubernetes-came-to-be-what-it-is-and-why-you-should-care/'>Primer: How Kubernetes Came to Be, What It Is, and Why You Should Care</BadgeLink>
+<BadgeLink colorScheme='yellow' badgeText='Read' href='https://thenewstack.io/kubernetes-an-overview/'>Kubernetes: An Overview</BadgeLink>