Adding content to 110-application-layer and 113-asynchronism

src/roadmaps/system-design/content/110-application-layer/100-microservices.md

@@ -1 +1,10 @@
 # Microservices
+
+Related to this discussion are microservices, which can be described as a suite of independently deployable, small, modular services. Each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal. 1
+
+Pinterest, for example, could have the following microservices: user profile, follower, feed, search, photo upload, etc.
+
+To learn more, visit the following links:
+
+- [Intro to Microservice](https://github.com/donnemartin/system-design-primer#microservices)
+- [Building Microservices](https://cloudncode.wordpress.com/2016/07/22/msa-getting-started/)

src/roadmaps/system-design/content/110-application-layer/101-service-discovery.md

@@ -1 +1,8 @@
-# Service discovery
+# Service Discovery
+
+Systems such as Consul, Etcd, and Zookeeper can help services find each other by keeping track of registered names, addresses, and ports. Health checks help verify service integrity and are often done using an HTTP endpoint. Both Consul and Etcd have a built in key-value store that can be useful for storing config values and other shared data.
+
+Visit the following links to learn more:
+
+- [What is Service-oriented architecture?](https://en.wikipedia.org/wiki/Service-oriented_architecture)
+- [Intro to Service Discovery](https://github.com/donnemartin/system-design-primer#Service%20Discovery)

src/roadmaps/system-design/content/110-application-layer/index.md

@@ -1 +1,7 @@
-# Application layer
+# Application Layer
+
+Separating out the web layer from the application layer (also known as platform layer) allows you to scale and configure both layers independently. Adding a new API results in adding application servers without necessarily adding additional web servers. The single responsibility principle advocates for small and autonomous services that work together. Small teams with small services can plan more aggressively for rapid growth.
+
+For more resources, visit the following links:
+
+- [Getting started with Application Layer](https://github.com/donnemartin/system-design-primer#Application%20layer)

src/roadmaps/system-design/content/113-asynchronism/100-message-queues.md

@@ -1 +1,23 @@
-# Message queues
+# Message Queues
+
+Message queues receive, hold, and deliver messages. If an operation is too slow to perform inline, you can use a message queue with the following workflow:
+
+- An application publishes a job to the queue, then notifies the user of job status
+- A worker picks up the job from the queue, processes it, then signals the job is complete
+
+The user is not blocked and the job is processed in the background. During this time, the client might optionally do a small amount of processing to make it seem like the task has completed. For example, if posting a tweet, the tweet could be instantly posted to your timeline, but it could take some time before your tweet is actually delivered to all of your followers.
+
+## Redis 
+It is useful as a simple message broker but messages can be lost.
+
+## RabbitMQ 
+This is popular but requires you to adapt to the 'AMQP' protocol and manage your own nodes.
+
+## Amazon SQS
+Amazon SQS is hosted but can have high latency and has the possibility of messages being delivered twice.
+
+To learn more, visit the following links:
+
+- [What is Redis?](https://redis.io/)
+- [RabbitMQ in Message Queues](https://www.rabbitmq.com/)
+- [Overview of Amazon SQS](https://aws.amazon.com/sqs/)

src/roadmaps/system-design/content/113-asynchronism/101-task-queues.md

@@ -1 +1,10 @@
-# Task queues
+# Task Queues
+
+Tasks queues receive tasks and their related data, runs them, then delivers their results. They can support scheduling and can be used to run computationally-intensive jobs in the background.
+
+Celery has support for scheduling and primarily has python support.
+
+To learn more, visit the following links:
+
+- [Overview of Task Queues](https://github.com/donnemartin/system-design-primer#task%20queues)
+- [Celery - Distributed Task Queue](https://docs.celeryq.dev/en/stable/)

src/roadmaps/system-design/content/113-asynchronism/102-back-pressure.md

@@ -1 +1,7 @@
-# Back pressure
+# Back Pressure
+
+If queues start to grow significantly, the queue size can become larger than memory, resulting in cache misses, disk reads, and even slower performance. Back pressure can help by limiting the queue size, thereby maintaining a high throughput rate and good response times for jobs already in the queue. Once the queue fills up, clients get a server busy or HTTP 503 status code to try again later. Clients can retry the request at a later time, perhaps with exponential backoff.
+
+To learn more, visit the following links:
+
+- [Overview of Back Pressure](https://github.com/donnemartin/system-design-primer#back%20pressure)

src/roadmaps/system-design/content/113-asynchronism/index.md

@@ -1 +1,8 @@
 # Asynchronism
+
+Asynchronous workflows help reduce request times for expensive operations that would otherwise be performed in-line. They can also help by doing time-consuming work in advance, such as periodic aggregation of data.
+
+To learn more, visit the following links:
+
+- [Overview of Asynchronism](https://github.com/donnemartin/system-design-primer#Asynchronism)
+- [What is the difference between a message queue and a task queue?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)