mirror of
https://github.com/ByteByteGoHq/system-design-101.git
synced 2026-04-03 01:17:23 -04:00
ee4b7305a2
This PR adds all the guides from [Visual Guides](https://bytebytego.com/guides/) section on bytebytego to the repository with proper links. - [x] Markdown files for guides and categories are placed inside `data/guides` and `data/categories` - [x] Guide links in readme are auto-generated using `scripts/readme.ts`. Everytime you run the script `npm run update-readme`, it reads the categories and guides from the above mentioned folders, generate production links for guides and categories and populate the table of content in the readme. This ensures that any future guides and categories will automatically get added to the readme. - [x] Sorting inside the readme matches the actual category and guides sorting on production
43 lines
2.0 KiB
Markdown
43 lines
2.0 KiB
Markdown
---
|
||
title: "How AWS Lambda Works Behind the Scenes"
|
||
description: "Explore the inner workings of AWS Lambda and its serverless architecture."
|
||
image: "https://assets.bytebytego.com/diagrams/0249-lambda.jpg"
|
||
createdAt: "2024-01-26"
|
||
draft: false
|
||
categories:
|
||
- cloud-distributed-systems
|
||
tags:
|
||
- "AWS Lambda"
|
||
- "Serverless"
|
||
---
|
||
|
||
|
||
|
||
**Serverless** is one of the hottest topics in cloud services. How does AWS **Lambda** work behind the scenes?
|
||
|
||
Lambda is a **serverless** computing service provided by Amazon Web Services (AWS), which runs functions in response to events.
|
||
|
||
## Firecracker MicroVM
|
||
|
||
Firecracker is the engine powering all of the Lambda functions. It is a virtualization technology developed at Amazon and written in Rust.
|
||
|
||
The diagram below illustrates the isolation model for AWS Lambda Workers.
|
||
|
||
Lambda functions run within a sandbox, which provides a minimal Linux userland, some common libraries and utilities. It creates the Execution environment (worker) on EC2 instances.
|
||
|
||
How are lambdas initiated and invoked? There are two ways.
|
||
|
||
## Synchronous execution
|
||
|
||
* Step1: "The Worker Manager communicates with a Placement Service which is responsible to place a workload on a location for the given host (it’s provisioning the sandbox) and returns that to the Worker Manager".
|
||
|
||
* Step 2: "The Worker Manager can then call *Init* to initialize the function for execution by downloading the Lambda package from S3 and setting up the Lambda runtime"
|
||
|
||
* Step 3: The Frontend Worker is now able to call *Invoke*.
|
||
|
||
## Asynchronous execution
|
||
|
||
* Step 1: The Application Load Balancer forwards the invocation to an available Frontend which places the event onto an internal queue(SQS).
|
||
|
||
* Step 2: There is "a set of pollers assigned to this internal queue which are responsible for polling it and moving the event onto a Frontend synchronously. After it’s been placed onto the Frontend it follows the synchronous invocation call pattern which we covered earlier".
|