Concurrency means multiple tasks making progress at the same time.

It does not always mean running at the exact same moment (that is parallelism). Instead, concurrency is about structuring programs so many tasks can progress independently.

2. Why Go Uses Goroutines + Channels?

Go was designed to make concurrency simple and scalable.

Instead of relying on heavy threads and complicated locking, Go introduced two core primitives:

2.1 Goroutines

Lightweight concurrent functions. A goroutine is much cheaper than a traditional thread. You can run hundreds of thousands of them.

2.2 Channels

A channel in Go is a communication mechanism that allows goroutines to send and receive data safely.

Think of a channel as a typed pipe through which values flow between goroutines.

Channels are powerful because they provide three guarantees:

2.2.1. Safe Communication

Channels synchronize goroutines automatically. Send blocks until receive happens, this ensures safe coordination.

2.2.2. Built-in Synchronization

Channels remove the need for:

• mutexes

• locks

• condition variables

2.2.3. Structured Concurrency Patterns

Channels enable powerful patterns such as:

• One-to-One communication

• Fan-Out (one producer, many workers)

• Fan-In (many producers, one consumer)

• Pipelines

• Broadcast

• Worker pools

These patterns make Go programs clean, scalable, and easy to reason about.

3. Channel Type Safety

Channels in Go are strongly typed. This means a channel can only send and receive one specific type of data.

Example:

ch := make(chan int)

This channel can only transmit integers.

Valid:

ch <- 10

Invalid:

ch <- "hello"   // compile-time error

This type safety prevents many runtime bugs and makes concurrent code more predictable.

4. Channel Syntax

Channels have a simple syntax consisting of three main operations.

4.1. Creating a Channel

Channels are created using the make function.

make(chan T)

Where:

• T = type of data the channel carries

Example:

ch := make(chan int)

This creates a channel capable of sending and receiving integers.

4.2. Sending Data to a Channel

Data is sent to a channel using the arrow operator.

ch <- value

Example:

ch <- 5

This means: send value 5 into channel ch

Usually this is done inside a goroutine.

go func() {
    ch <- 5
}()

4.3. Receiving Data from a Channel

To receive a value from a channel:

value := <-ch

Example:

num := <-ch
fmt.Println(num)

This means: take a value from channel ch and store it in num

5. Blocking Behavior of Channels

One of the most important characteristics of channels is blocking behavior.

Channels automatically synchronize goroutines.

5.1. Send Blocks

When sending:

ch <- value

The goroutine waits until another goroutine receives the value.

5.2. Receive Blocks

When receiving:

value := <-ch

The goroutine waits until a value is available in the channel.

5.3. Visualization

Sender --- waiting ---> Channel <--- waiting --- Receiver

Both sides must be ready.

This property is what makes channels safe for concurrency without locks.

6. Channel Direction in Go

Channels in Go can restrict how they are used.

A channel can be:

• Bidirectional : send and receive

• Send-only : only send values

• Receive-only : only receive values

This restriction happens at compile time, preventing misuse of channels.

6.1. Bidirectional Channels

A bidirectional channel allows both sending and receiving.

Syntax:

chan T

Example:

ch := make(chan int)

ch <- 10        // send
value := <-ch   // receive

Here the channel can perform both operations.

This is the default channel type in Go.

6.2. Send-Only Channels

A send-only channel allows only sending data.

Syntax:

chan<- T

Example:

func sendData(ch chan<- int) {
    ch <- 10
}

Inside this function:

Sending is allowed

ch <- 10

Receiving is NOT allowed

value := <-ch   // compile-time error

This restriction ensures the function only produces data.

6.3. Receive-Only Channels

A receive-only channel allows only receiving data.

Syntax:

<-chan T

Example:

func receiveData(ch <-chan int) {
    value := <-ch
    fmt.Println(value)
}

Inside this function:

Receiving is allowed

value := <-ch

Sending is NOT allowed

ch <- 10   // compile-time error

7. Converting Channel Direction

A bidirectional channel can be converted to a directional one.

Example:

func producer(ch chan<- int) {
    ch <- 5
}

func consumer(ch <-chan int) {
    value := <-ch
    fmt.Println(value)
}

func main() {
    ch := make(chan int)

    go producer(ch)
    consumer(ch)
}

Here:

main -> bidirectional channel
producer -> send-only channel
consumer -> receive-only channel

Go automatically converts the channel type.

8. Channel Behavior in Go

Channels in Go can behave in two different ways depending on how they are created:

1. Unbuffered Channels : synchronous communication

2. Buffered Channels : asynchronous communication

The difference lies in whether the channel has storage capacity (a buffer).

This behavior directly affects how goroutines coordinate with each other.

8.1. Synchronous Communication (Unbuffered Channels)

An unbuffered channel has no storage capacity.

This means a value cannot exist in the channel alone.
A sender and receiver must meet at the same time for communication to occur.

Since no capacity is provided, the channel is unbuffered by default.

Flow:

Receiver ---- waiting ---> Channel <--- waiting --- Sender

8.2. Asynchronous Communication (Buffered Channels)

A buffered channel has internal storage capacity.

This allows values to be stored temporarily inside the channel.

Creation syntax:

ch := make(chan int, 3)

Here: channel capacity = 3

The channel can hold 3 values before blocking.

Buffer Capacity

The number given during creation defines the buffer size.

Example:

ch := make(chan int, 2)

This channel can store [ value1 | value2 ] inside its internal buffer.

Queue-like Behavior

Buffered channels behave like a FIFO queue (First-In-First-Out).

Example:

ch := make(chan int, 3)

ch <- 1
ch <- 2
ch <- 3

Internal buffer: [1 | 2 | 3]

Receiving values:

fmt.Println(<-ch)
fmt.Println(<-ch)
fmt.Println(<-ch)

Output:

1
2
3

Values come out in the same order they were sent.

9. Basic Communication Patterns

Channels enable different communication patterns between goroutines.
These patterns define how data flows between concurrent tasks.

The most basic patterns are:

1. One-way communication

2. Two-way communication (Request–Response)

Understanding these patterns helps design structured concurrent systems.

9.1. One-way Communication

In one-way communication, data flows in a single direction between goroutines.

There is one sender and one receiver, and no response is expected.

Two common forms are:

1. Main -> Goroutine

2. Goroutine -> Main

9.1.1. Main -> Goroutine

In this pattern, the main goroutine acts as the producer, sending data to another goroutine that performs some work.

Flow:

Main ---> Channel ---> Worker Goroutine

Example:

package main

import "fmt"

func worker(ch <-chan int) {
	value := <-ch
	fmt.Println("Worker received:", value)
}

func main() {

	ch := make(chan int)

	go worker(ch)

	ch <- 10
}

Execution flow:

1. Main creates the channel

2. Worker goroutine starts and waits for data

3. Main sends value 10

4. Worker receives and processes it

Output:

Worker received: 10

Here the worker only consumes data.

9.1.2. Goroutine -> Main

In this pattern, a worker goroutine produces a result, and the main goroutine receives it.

Flow:

Worker Goroutine ---> Channel ---> Main

Example:

package main

import "fmt"

func compute(ch chan<- int) {
	result := 5 * 5
	ch <- result
}

func main() {

	ch := make(chan int)

	go compute(ch)

	result := <-ch

	fmt.Println("Result:", result)
}

9.2. Two-way Communication (Request–Response)

A component sends a request, and another component sends a response.

This pattern is called request–response communication.

Flow:

Client --> Request Channel --> Worker --> Response Channel --> Client

9.2.1. Using Two Channels

The simplest approach uses two separate channels.

Example:

package main

import "fmt"

func worker(requests <-chan int, responses chan<- int) {
	req := <-requests
	responses <- req * 2
}

func main() {

	requestCh := make(chan int)
	responseCh := make(chan int)

	go worker(requestCh, responseCh)

	requestCh <- 10

	result := <-responseCh

	fmt.Println("Response:", result)
}

Execution flow:

1. Main sends a request

2. Worker receives the request

3. Worker processes it

4. Worker sends response

5. Main receives result

Output:

Response: 20

9.2.2. Reply Channels (More Scalable)

A more advanced approach uses reply channels embedded in the request.

Flow:

Client --> Request{data, replyChannel} --> Worker --> replyChannel --> Client

Example:

package main

import "fmt"

type Request struct {
	data  int
	reply chan int
}

func worker(reqCh <-chan Request) {

	req := <-reqCh

	result := req.data * 2

	req.reply <- result
}

func main() {

	reqCh := make(chan Request)

	go worker(reqCh)

	replyCh := make(chan int)

	reqCh <- Request{
		data:  10,
		reply: replyCh,
	}

	result := <-replyCh

	fmt.Println("Response:", result)
}

Output:

Response: 20

10. Channel Communication Topologies

These describe how goroutines are connected through channels.

10.1. One to One

Single producer -> single consumer

Similar concept as the One Way Communication

10.2. One to Many (Fan-Out)

In this topology, one producer distributes work to multiple workers.

Key Idea:

Multiple goroutines compete to receive from the same channel.

Important Rule:

Each job is processed by exactly one worker because a channel delivers a value to only one receiver.

Use Case

• Parallel processing

• CPU-intensive tasks

• Worker pools

Example

package main

import (
	"fmt"
	"time"
)

func worker(id int, jobs <-chan int) {
    // Keep receiving values from the channel until it is closed
	for job := range jobs { 
		fmt.Println("Worker", id, "processing job", job)
		time.Sleep(time.Millisecond * 500)
	}
}

func main() {

	jobs := make(chan int)

	// Start 3 workers
	for i := 1; i <= 3; i++ {
		go worker(i, jobs)
	}

	// Send jobs
	for j := 1; j <= 5; j++ {
		jobs <- j
	}

	close(jobs)
	time.Sleep(time.Second * 2)
}

Work is distributed automatically.

10.3. Many to One (Fan-In)

In this topology, multiple producers send data to a single consumer.

Key Idea

Many goroutines produce results, and one goroutine collects them.

Use Case

• Aggregating results

• Merging streams

• Logging systems

Example

package main

import "fmt"

func worker(id int, results chan<- int) {
	results <- id * 10
}

func main() {

	results := make(chan int)

	for i := 1; i <= 3; i++ {
		go worker(i, results)
	}

	for i := 1; i <= 3; i++ {
		fmt.Println("Result:", <-results)
	}
}

10.4. Many to Many

This is the most flexible topology.

• Multiple producers

• Multiple consumers

• All connected through shared channels

Use Case

• Worker pools

• Distributed processing

• Task queues

• High-throughput systems

Example

package main

import "fmt"

func producer(id int, ch chan<- int) {
	for i := 1; i <= 3; i++ {
		ch <- id*10 + i
	}
}

func consumer(id int, ch <-chan int) {
	for val := range ch {
		fmt.Println("Consumer", id, "received", val)
	}
}

func main() {

	ch := make(chan int)

	// Producers
	for i := 1; i <= 2; i++ {
		go producer(i, ch)
	}

	// Consumers
	for i := 1; i <= 3; i++ {
		go consumer(i, ch)
	}

	// Let it run briefly
	select {}
}

11. Coordination and Control

Channels are not just for passing data — they are powerful tools for coordinating goroutines.

They help answer questions like:

• When should a goroutine stop?

• How do multiple goroutines react to a single event?

• How do we wait for multiple events?

This section covers control-oriented patterns using channels.

11.1. Broadcast Communication

Broadcast means one signal wakes up multiple goroutines.

Concept: close(channel)

When a channel is closed, all goroutines waiting to receive from it are unblocked immediately.

close(ch)

Any receive operation:

<-ch

will now proceed instantly.

Key Idea: Closing a channel acts like a broadcast signal

Example

package main

import (
	"fmt"
	"time"
)

func worker(id int, done <-chan struct{}) {
	<-done
	fmt.Println("Worker", id, "stopping")
}

func main() {

	done := make(chan struct{})

	for i := 1; i <= 3; i++ {
		go worker(i, done)
	}

	time.Sleep(time.Second)

	close(done) // broadcast signal

	time.Sleep(time.Second)
}

Use Cases

• Graceful shutdown

• Cancellation signals

• Stopping worker pools

11.2. Signal-Only Communication

Sometimes you don’t need to send data, only a signal.

Concept: chan struct{}

done := make(chan struct{})

Here:

struct{} = empty type (no data)

Why use struct{}?

• Zero allocation

• No memory overhead

• Pure signaling

Example

package main

import "fmt"

func main() {

	done := make(chan struct{})

	go func() {
		fmt.Println("Work done")
		done <- struct{}{}
	}()

	<-done
	fmt.Println("Received signal")
}

Use Cases

• Done signals

• Event notifications

• Synchronization triggers

11.3. Non-Blocking Communication

By default, channel operations block.

Sometimes you want to avoid waiting.

Concept: select + default

select {
case ch <- value:
	// sent successfully
default:
	// fallback (non-blocking)
}

Example

package main

import "fmt"

func main() {

	ch := make(chan int)

	select {
	case ch <- 10:
		fmt.Println("Sent")
	default:
		fmt.Println("Channel not ready, skipping")
	}
}

Behavior

• If send/receive is possible -> it executes

• Otherwise -> default runs immediately

Use Cases

• Polling systems

• Avoiding deadlocks

• Building responsive systems

11.4. Multiplexed Communication (select)

The select statement allows a goroutine to wait on multiple channels simultaneously.

Concept

select {
case <-ch1:
	// event from ch1
case <-ch2:
	// event from ch2
}

Key Idea: Whichever channel is ready first wins

Example

package main

import (
	"fmt"
	"time"
)

func main() {

	ch1 := make(chan string)
	ch2 := make(chan string)

	go func() {
		time.Sleep(time.Second)
		ch1 <- "from ch1"
	}()

	go func() {
		time.Sleep(2 * time.Second)
		ch2 <- "from ch2"
	}()

	select {
	case msg := <-ch1:
		fmt.Println(msg)
	case msg := <-ch2:
		fmt.Println(msg)
	}
}

Output:

from ch1

With Timeout

select {
case res := <-ch:
	fmt.Println(res)
case <-time.After(time.Second):
	fmt.Println("timeout")
}

Use Cases

• Orchestration between goroutines

• Timeout handling

• Cancellation patterns

• Event-driven systems

12. Time-Based Communication

In Go, time is not just a utility — it becomes part of your concurrency model.

Instead of writing blocking logic like:

sleep(5 seconds)

Go lets you communicate with time using channels.

Core Idea: Go’s time package provides channels that send signals based on time.

12.1. Timeout using time.After

Concept: time.After(duration) returns a channel that sends a signal after a delay.

Example

select {
case msg := <-ch:
    fmt.Println("Received:", msg)

case <-time.After(2 * time.Second):
    fmt.Println("Timeout!")
}

Explanation

• If ch responds -> success

• If nothing happens for 2 seconds -> timeout triggers

This prevents goroutine blocking forever

Use Cases

• API calls

• Worker jobs

• Waiting for responses

12.2. Periodic Tasks using time.Tick

Concept: time.Tick(interval) returns a channel that sends signals repeatedly.

Example

ticker := time.Tick(1 * time.Second)

for {
    select {
    case <-ticker:
        fmt.Println("Running every second")
    }
}

Explanation

• Every 1 second -> signal is received

• Loop keeps running forever

Important: time.Tick cannot be stopped

Better approach:

ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()

Use Cases

• Background jobs

• Metrics collection

• Polling systems

12.3. Fine Control using time.Timer

Concept: A Timer gives you manual control over timing

Example

timer := time.NewTimer(2 * time.Second)

<-timer.C
fmt.Println("Executed after delay")

Advanced Control

timer := time.NewTimer(2 * time.Second)

go func() {
    time.Sleep(1 * time.Second)
    timer.Stop()
}()

<-timer.C // may or may not fire

Why use Timer?

• Can stop or reset

• Better control than time.After

13. Pipeline Communication

Pipeline communication is about processing data in stages, where each stage does one job and passes the result forward.

Core Idea

A pipeline looks like this:

source --> stage1 --> stage2 --> stage3 --> output

Each stage:

• Runs in its own goroutine

• Communicates via channels

• Processes and forwards data

This creates a streaming flow of data

Why Pipelines?

Pipelines help you:

• Break complex work into smaller steps

• Process data concurrently

• Stream data instead of waiting for everything

Example

func generator(nums ...int) <-chan int {
    out := make(chan int)

    go func() {
        for _, n := range nums {
            out <- n
        }
        close(out)
    }()

    return out
}

func square(in <-chan int) <-chan int {
    out := make(chan int)

    go func() {
        for n := range in {
            out <- n * n
        }
        close(out)
    }()

    return out
}

func main() {
    nums := generator(1, 2, 3, 4)

    squared := square(nums)

    for result := range squared {
        fmt.Println(result)
    }
}

14. Context-Based Communication in Go

Context is how goroutines communicate control signals like:

• Cancellation

• Deadlines

• Request-scoped data

Core Idea: Context is not for data — it’s for control

What is context.Context?

It’s an interface provided by Go that allows you to:

• Cancel operations

• Set timeouts

• Pass request-level metadata

Key Concept: ctx.Done()

ctx.Done()

returns a channel that is closed when cancellation happens

Mental Model

ctx.Done() -> "Stop everything now"

Example (Cancellation)

ctx, cancel := context.WithCancel(context.Background())

go func() {
    for {
        select {
        case <-ctx.Done():
            fmt.Println("Stopped!")
            return
        default:
            fmt.Println("Working...")
            time.Sleep(500 * time.Millisecond)
        }
    }
}()

time.Sleep(2 * time.Second)
cancel()

What’s happening?

• Goroutine keeps working

• cancel() is called

• ctx.Done() channel closes

• Goroutine exits gracefully

15. Shared Memory Communication

Sometimes, using channels is not the best choice.

In those cases, goroutines share memory directly, and we control access using:

• sync.Mutex

• sync/atomic

Core Idea: Multiple goroutines access the same variable, but in a controlled way

15.1. sync.Mutex

A mutex ensures: “Only one goroutine can access this critical section at a time”

Example

var mu sync.Mutex
counter := 0

go func() {
    mu.Lock()
    counter++
    mu.Unlock()
}()

What’s happening?

• Lock() → enter critical section

• Unlock() → release access

Prevents race conditions

Important Rule

Always unlock:

mu.Lock()
defer mu.Unlock()

15.2. sync/atomic

Concept

Atomic operations are: “Low-level, lock-free, super-fast operations”

Example

var counter int32

go func() {
    atomic.AddInt32(&counter, 1)
}()

Why atomic?

• No locking overhead

• Faster than mutex

• Safe for simple operations

16. Waiting for Goroutines (sync.WaitGroup)

Basic Usage

A WaitGroup has three main methods:

• Add(n) → number of goroutines to wait for

• Done() → called when a goroutine finishes

• Wait() → blocks until all are done

Example

package main

import (
	"fmt"
	"sync"
)

func worker(id int, wg *sync.WaitGroup) {
	defer wg.Done() // signal completion
	fmt.Println("Worker", id, "done")
}

func main() {

	var wg sync.WaitGroup

	for i := 1; i <= 3; i++ {
		wg.Add(1) // register goroutine
		go worker(i, &wg)
	}

	wg.Wait() // wait for all workers
	fmt.Println("All workers finished")
}

Execution Flow

wg.Add(1) increases the counter

• Each goroutine calls wg.Done() when finished

• wg.Wait() blocks until the counter becomes zero

Important Rules

• Always call Add() before starting the goroutine

• Always use defer wg.Done() inside goroutines

• Do not copy a WaitGroup (always pass by pointer)

When to Use WaitGroup

• Waiting for multiple goroutines to finish

• Coordinating parallel tasks

• Ensuring graceful program completion

WaitGroup vs Channels

• WaitGroup -> used for waiting

• Channels -> used for communication

They are often used together in real-world systems.

17. Conclusion

Go’s concurrency model is both simple and powerful. With goroutines and channels, you can build systems where tasks run independently while staying safely coordinated. Instead of managing threads and locks, Go encourages a design based on communication and data flow.

Channels act as both data pipelines and synchronization points, making concurrent programs easier to understand and scale. Combined with tools like select, time, and context, they help handle real-world challenges like timeouts and cancellation.

The key idea is: share memory by communicating. Once you adopt this mindset, writing clean and efficient concurrent systems in Go becomes much more intuitive.

This blog explains goroutines from the ground up and then dives deep into how Go schedules them using the GMP scheduler model. Everything here focuses on how things actually work.

What is Goroutine?

A goroutine is a lightweight unit of execution managed entirely by the Go runtime, not by the operating system.

Key characteristics of goroutines:

• Lightweight compared to OS threads

• Dynamically growing stack

• User-space threads

• Exist within the same address space

• Managed by the Go runtime scheduler

• Multiplexed onto OS threads

• Initial stack size is ~2 KB

• Communicate via channels or shared memory

Go promotes a strong concurrency principle:

Do not communicate by sharing memory; instead, share memory by communicating.

This philosophy is central to Go’s design and is the reason channels are preferred over locks in many cases.

Goroutines vs OS Threads

Goroutines are not OS threads.

• OS threads are heavyweight, expensive to create, and managed by the OS

• Goroutines are lightweight, cheap to create, and managed by Go

A Go program can run thousands or even millions of goroutines, which would be impossible with OS threads alone.

Goroutines Are Managed by the Go Runtime

Some important points:

• Goroutines are scheduled in user space

• The OS does not know about goroutines

• The Go runtime maps goroutines onto OS threads

• Multiple goroutines can run on a single OS thread

• Multiple OS threads can exist inside one Go process

This mapping is handled using the GMP scheduler model.

The GMP Scheduler Model

The Go scheduler internally uses the GMP model:

• G : Goroutine

• M : Machine (OS Thread)

• P : Processor (Logical scheduling context)

This model defines how goroutines are executed efficiently across CPU cores.

G : Goroutine

A G represents a goroutine.

It contains:

• Stack

• Program Counter

• CPU registers

• Metadata (state, ID, etc.)

A goroutine cannot execute by itself. It must be:

• Assigned to a P (processor)

• Executed by an M (machine)

M : Machine (OS Thread)

• Represents an OS thread

• Created by the Go runtime

• Executes Go code

• An M must acquire a P to run goroutines

P : Processor (Logical Execution Context)

A P represents execution capacity.

Each P :

• Holds a local run queue of goroutines, when a goroutine is created, it is added to the local queue of the currently running P, initially, many goroutines may accumulate on a single P.

• Contains scheduler state

• Controls parallel execution

Key rule:

Parallelism is limited by the number of P, not by goroutines or OS threads.

The number of P is controlled by: GOMAXPROCS, by default, it equals the number of logical CPUs.

Important detail:

The number of OS threads (M) can be greater than the number of processors (P).

Why?

• OS threads can block on system calls or I/O

• Go creates extra threads to avoid stalling execution

How Goroutines Are Executed (High-Level Flow)

1. Many Goroutines (G) are created by the program

2. Each newly created goroutine is placed into the local run queue of a Processor (P)

3. Each Processor (P) manages its own queue of runnable goroutines

4. An OS thread (M) acquires a Processor (P)

5. The OS thread (M) picks a goroutine (G) from the P’s local run queue

6. The OS thread (M) executes the goroutine (G)

7. The goroutine runs on the CPU until it blocks, completes, or is preempted

Global Run Queue

Go also maintains a global run queue.

Purpose:

• Ensure fairness

• Handle load balancing

• Support scheduling when local queues are empty or unsuitable

The scheduler periodically pulls goroutines from the global queue to avoid starvation.

Work Stealing

If a P runs out of runnable goroutines:

• It steals half of the runnable goroutines

• From another P’s local run queue

• Keeps CPU cores busy

• Maximizes parallelism

This mechanism is called work stealing and is crucial for Go’s scalability.

What Happens When a Goroutine Blocks?

When a goroutine:

• Performs a blocking system call

• Waits on I/O

• Sleeps

• Waits on a channel

Then:

• The M releases its P

• Another M can acquire that P

• Execution continues without blocking the entire scheduler

This design ensures that blocking operations do not reduce parallelism.

M and P Relationship

Important observations:

• An OS thread (M) holds a P only while executing Go code

• Blocking, preemption, or scheduling can cause it to release the P

• Each OS thread can execute many goroutines over time

• Only one goroutine runs at a time per P

Goroutine Creation Timing

A very common misconception:

A goroutine is enqueued when the go statement executes, not when the function is declared.

go doWork()

At this moment:

• A new G is created

• It is placed into a P's run queue

• Scheduler decides when it runs

Program Startup Flow

When a Go program starts:

1. The runtime creates multiple P (based on GOMAXPROCS)

2. Each P gets its own local run queue

3. The initial OS thread acquires a P

4. The main goroutine is placed into that P’s run queue

5. Execution begins

Over time, goroutines are redistributed across P using work stealing and the global queue.

Lifecycle of a Goroutine

Created → Runnable → Running → Blocked → Runnable → Terminated

• Created: Goroutine is instantiated

• Runnable: Waiting in a run queue

• Running: Actively executing

• Blocked: Waiting on I/O, syscall, channel, etc.

• Terminated: Execution finished

Why the GMP Model Works So Well

The GMP scheduler allows Go to:

• Scale efficiently across CPU cores

• Avoid excessive OS thread creation

• Handle blocking operations gracefully

• Maximize CPU utilization

• Keep concurrency simple for developers

All while writing code as simple as:

go func() { // concurrent work }()

Final Thoughts

Goroutines may look simple, but the Go scheduler is doing a huge amount of work behind the scenes.

Understanding:

• Goroutines (G)

• OS threads (M)

• Processors (P)

• Local and global queues

• Work stealing

• Blocking behavior

…gives you a clear mental model of how Go concurrency actually works.

Once you understand GMP, Go’s concurrency stops feeling magical and starts feeling predictable, powerful, and elegant.

The topics and theories of our favorite subject, system design, are inspired by the famous book "System Design Interview" by Alex Xu. This article aims to build the foundation of system design, covering basic concepts that will be used as we progress to designing systems that can handle users from zero to millions.

And since I’m a big My Hero Academia fan (guilty as charged!), you might notice a quote or two sneaking in along the way. As All Might says: “Go beyond! Plus Ultra!”

Why Basics Matter

These concepts are the foundation of every system design journey. Whether you’re building something simple like a rate limiter or designing a full-fledged application like Instagram, the same building blocks apply. It might be too soon to dive into Instagram-level systems but don’t worry, we’ll definitely get there.

As Midoriya once said:
“There was a time in my life when I would’ve given up, but I kept pushing forward.”

That’s exactly how learning system design feels challenging at first, but step by step, you’ll go beyond.

Core Concepts of System Design

Let's dive into the main part of the blog.

1. Single Server Setup

The adventure of computing and services begins with a single server, a user, and the all-knowing DNS server.

A user types in a domain name. The DNS translates this human-friendly name into the IP address of the server, and suddenly the user knows where to find it. It’s like the user only knows the nickname of the server, but the DNS knows its home address. And if you want to gossip with the server, you need to go knock at its door that’s the IP address.

In this setup, everything the application code, the database, and the storage lives on one machine.

Think of a single hero (like Midoriya in his early days) fighting all the villains alone. He can protect a small area, but if too many villains show up at once, he gets overwhelmed.
One server = one hero doing everything.

2. Database

As more users join, a single server can’t handle everything both running the app and storing all the data. So, we bring in a database whose main job is to store and organize information. The server just asks the database whenever it needs to save or read something.

A hero might have amazing memory storing all the details about villains, battles, and strategies. But when the workload gets heavier, the hero writes everything down in a Hero Logbook (like All Might passing down his notebook to Midoriya).
The database = the hero’s logbook where all important info is stored.

There are mainly two kinds of databases:

Relational Databases (SQL)

• Think of it like spreadsheets with rows and columns.

• You can connect different tables (like a table of users and a table of orders).

• Very organized, great when your data has a clear structure.

• Examples: MySQL, PostgreSQL.

Non-Relational Databases (NoSQL)

• Instead of tables, they store data more freely, often like JSON files.

• Flexible, good for apps where the data shape changes a lot.

• Easy to grow across many servers when traffic is huge.

• Examples: MongoDB, DynamoDB.

In short:

• Use SQL when your data is neat and well-organized.

• Use NoSQL when your data is messy, flexible, or growing super fast.

3. Vertical Scaling VS Horizontal Scaling

Think about your own device — a laptop, PC, or even your smartphone. If it starts running slow because the CPU, RAM, or storage isn’t enough, you have two choices:

Vertical Scaling (Scale Up)

• This is like upgrading your device with better parts.

• Add more RAM, replace the CPU with a faster one, or upgrade to a bigger SSD.

• In servers, vertical scaling means giving a single machine more power.

• Simple to do.

• But there’s a limit you can’t keep upgrading forever, and it gets expensive.

Horizontal Scaling (Scale Out)

• Instead of buying one super-powerful laptop, imagine having multiple laptops working together.

• Each laptop handles part of the workload, and together they can do much more.

• In servers, this means adding more machines and distributing the traffic among them.

• Much higher capacity, no single point of failure.

• More complex to manage because you need load balancers and coordination.

In short:

• Vertical scaling = making one server stronger.

• Horizontal scaling = adding more servers to share the work.

• Vertical Scaling: Midoriya unlocking 100% of One For All to become way stronger. One hero, but much more powerful.

• Horizontal Scaling: Instead of just Midoriya fighting, the entire Class 1-A joins in. Each hero handles part of the battle, and together they defeat the villains.

Vertical \= powering up one hero. Horizontal = teaming up multiple heroes.

4. Load Balancer

Imagine this: your device is so popular that many people want to use it at the same time. But one device can’t handle everyone at once. So, instead of forcing them to fight over it, you give each person a different device to use.

That’s what a load balancer does in system design.

Think of Eraser Head (Aizawa) during training. When the students face too many combat exercises, he splits the class into groups and assigns each villain fight to the right student based on their quirk.
Load balancer = the teacher who distributes the workload to the right heroes.

Here’s how it works step by step:

1. The user types in the website name.

2. DNS gives back the IP address of the load balancer (not the server directly).

3. The user sends the request to the load balancer.

4. The load balancer then decides which server should handle that request.

The load balancer makes sure that:

• No single server is overloaded.

• New servers can be added when traffic is high.

• Extra servers can be removed when traffic is low (saving costs).

In short:
A load balancer is like a traffic manager it takes all incoming requests and spreads them evenly across available servers so that the system stays fast and reliable.

5. Database Replication

Imagine you save important files on your laptop, but the hard drive crashes. If you had made a backup copy on an external drive, you’d still be safe.

That’s exactly the idea behind database replication in system design — making copies of your database so your system doesn’t break if one fails.

Here’s how it usually works:

Master–Slave Setup

• Master Database: Handles all the write operations (adding, updating, or deleting data).

• Slave Databases: Receive copies of the master’s data and handle the read operations.

• If the master fails, one of the slaves can be promoted to act as the new master.

Why it’s useful

• Increases reliability, even if one database crashes, you don’t lose everything.

• Improves performance, reads can be spread across many slaves, avoiding overload on a single database.

• Helps with scaling as the system grows.

One trade-off: sometimes the slave might not have the very latest data at the exact moment of failure (called replication lag), but it’s usually close enough and can be fixed once the system recovers.

In short:
Database replication = having multiple copies of your database so your system stays safe, fast, and available

6. Cache

Imagine every time you open your laptop or phone, it has to load something important (like your wallpaper or your most-used app) from the hard drive (HDD). Hard drives are slower, so this would take time.

But if the device keeps that data in a cache (a small, super-fast memory), it can load it instantly.

In system design, a cache works the same way:

• It stores frequently accessed data in a faster storage layer (like in-memory).

• So instead of going all the way to the database every time, the server can quickly fetch the data from the cache.

Benefits of caching

• Speed: Faster responses for users.

• Reduced load: Fewer trips to the database.

• Cost saving: Less strain on expensive resources.

Example:
Think of logging into Instagram. Your profile picture, username, and bio don’t change every second. So instead of fetching them from the database every single time, Instagram puts them in a cache so they load instantly when you open the app.

In short:
Cache = a shortcut to the data you need most often. It makes systems faster and smoother.

How These Fit Together

All the pieces we’ve covered servers, databases, scaling, load balancers, replication, and caching work like parts of a small city:

• Server = the office where work happens

• Database = the record room

• Scaling = making the office bigger or opening more branches

• Load balancer = the receptionist guiding visitors

• Replication = backup record rooms

• Cache = quick-access drawer with popular files

Together, they form a basic but reliable system that can handle more users, stay available, and run faster.

Conclusion

We’ve taken the first big step into system design, from a single server all the way to caching and replication. These building blocks form the foundation of any scalable system and will keep showing up no matter what you design.

But this is just the beginning. In the next blog, we’ll go beyond the basics and explore more advanced topics like CDNs, stateless web tiers, data centers, message queues, and what it really takes to scale to millions of users. Stay tuned things are about to get even more exciting! 🚀

As All Might says: “When there’s nothing to be gained, rising to the challenge at those times… is surely the mark of a true hero.” 🌟

1. Open the AWS Management Console and navigate to the EC2.

2. Click “Launch instances”.

   

3. Enter an appropriate instance name.

4. Select “Amazon Linux” under “Application and OS Images”.

   

5. Select any “Free tier eligible” Instance type.

6. Create and select any “ppk key” of the “RSA” type.

7. Allow “SSH traffic”, “HTTPS traffic” and “HTTP traffic” under “Network settings”.

   

8. Click “Launch instance”.

Convert pem Key to ppk Key

1. Open “PuTTYgen”.

2. Click “Load”.

   

3. Now select the pem key you use instance.

4. Click on “Conversions” → “Export OpenSSH key” → “Yes”.

   

5. Enter an appropriate key name. (Eg. go-pem-key.ppm)

   Note: Make sure the save as type is “All Files” and to you use the “.ppm“ at the end of the key name as given in the example.

6. Click “Save”.

Connecting to EC2 instance

1. Copy this

    ssh -i "your-key.pem" ec2-user@<your-ec2-public-ip>
   

2. Paste in the Command Prompt.

3. Edit the pem key with the absolute path and the key name you just created. (Eg. If the absolute path is “C:\Users\username” and the key name is “go-pem-key.pem”. Then replace “you-key.pem” to “C:\Users\username\go-pem-key.pem”.

4. Go back to AWS Management console, Select the newly created instance.

5. Copy “Public IPv4 address”.

   

6. Replace <your-ec2-public-ip> to the copied address.

7. Press enter.

8. Type “yes” then again press enter.

Uploading Go webserver to EC2 instance

Note: Before uploading the go server to the EC2 instance the go server must set to run on default IP and 8080 port.

1. Copy and Paste the following one by one.

    sudo yum update -y
    sudo yum install -y golang
   

2. You can use scp to transfer your main.go, .env, and any other required files from your local machine to the EC2 instance.

   Copy the following

    scp -i "your-key.pem" -r "/path/to/your/project" ec2-user@<your-ec2-public-ip>:/home/ec2-user/
   

3. Paste this in another Command Prompt Terminal which is not connected to the EC2 instance.

4. Replace the "your-key.pem" to the pem key you created with the absolute path.

5. Replace the “/path/to/your/project” to the absolute path of your project (path to the root folder).

6. Replace the <your-ec2-public-ip> to the instance’s “Public IPv4 address”.

7. Hit Enter.

Build the application

1. Copy and Paste

    cd /home/ec2-user/your-project-folder
   

   Replace you-project-folder to the name of the root folder.

2. Hit enter.

3. Build your Go application to ensure it compiles properly:

    go build -o app main.go
   

Run the application

Once the build is successful, run the application:

./app

Run Your Application in the Background

To keep your application running after logging out, use a process manager like screen or tmux, or run the app as a background process.

nohup ./app &

Configure Security Group for HTTP Access

1. Select the EC2 instance.

2. Under “Security” click on the “Security groups”.

   

   

3. Scroll and click on “Inbound rules”.

4. Click on “Edit inbound rules”.

   

5. Click “Add Rules”.

6. Select “Custom TCP” under “Type”, set “8080” in “Port range” and “Anywhere-IPv4” under “Destination”.

   

7. Click “Save rules”.

8. Now Click on “Outbound Rules”.

9. Click “Edit outbound rules”.

   

10. Click “Add Rules”.

11. Select “Custom TCP” under “Type”, set “8080” in “Port range” and “Anywhere-IPv4” under “Destination”.

    

12. Click “Save rules”.

Test the Web Server

Use the curl command with the public IP and port.

For example curl http://<Public-IP>:8080/path_to _service.

Replace <Public-IP> with the instance’s Public IPv4 address and path-to-service with the path where any GET request is sent.

Docker is a platform that allows developers to package their applications into containers. These containers include everything the application needs to run, such as code, system libraries, and dependencies, ensuring the application behaves the same regardless of where it's executed.

Docker is a tool that makes it easier to create, deploy, and run applications in containers. It's widely used for packaging applications along with their dependencies and ensuring they run the same way on any machine.

The Problem Docker Solves:

Before Docker, developers faced a common issue called the “It works on my machine!” problem. This happens when an application works fine on a developer’s machine but encounters issues when run on another system or server. This is often caused by different software versions, missing dependencies, or environmental differences between systems.

Docker solves this problem by allowing developers to package their applications with all the necessary dependencies into a container. Since containers are consistent, lightweight, and isolated, the application will work the same no matter where it's run—on a developer's laptop, on a server, or in the cloud.

Containers

Containers are like small, portable boxes that hold everything your application needs to run. Inside the container, you have the code, all its libraries, system tools, and settings. This ensures that the application runs the same way no matter where you execute it.

Containers are lightweight, portable, and isolated environments that bundle an application and all its dependencies (libraries, configuration files, etc.) so that it can run consistently across different environments (like your computer, a server, or the cloud).

Why Use Containers?

Because they isolate your application and its environment from the rest of the system.

Think of it like packaging a dish with all its ingredients and the specific kitchen tools you need. No matter where you cook it (at home, a friend's house, a different city), the dish will turn out the same because you brought everything needed with you.

How Containers Differ from Virtual Machines (VMs)?

• Virtual Machines (VMs) simulate an entire physical computer. They include a full operating system (OS), which takes up a lot of space and system resources. They’re like heavy boxes that simulate a full, separate computer.

• Containers share the host operating system, meaning they don’t need a full OS inside them. This makes containers lightweight, faster to start, and more efficient in resource usage.

• VMs each have their own OS and take longer to boot up because of this.

Use Cases for Docker

Here’s where Docker shines—it helps you easily build, test, and deploy applications using containers.

• Development: Developers use Docker to create containers on their local machines. These containers mimic the production environment (the server where the app will run for real), so developers can ensure their app works correctly before they deploy it.

  Example: You're building a website on your laptop and you want to be sure it works the same on the actual server. With Docker, you can create a container that has all the same dependencies as the server, so you know the website will run perfectly on both.

• Testing: Testers can run applications in isolated containers. This means they can test different configurations or features without breaking anything on the main system.

  Example: Think of it like testing new ingredients in your dish, but in a separate kitchen. If something goes wrong, you didn’t mess up your original kitchen—it’s all isolated.

• Deployment: When the time comes to send the application to the cloud or servers, Docker containers make this easy because they work the same way on any machine.

  Example: Once you’ve made your dish in one kitchen and it worked great, you can take your packed ingredients and tools (the container) and cook it in a different kitchen (the server) without any issues.

Example to Relate:

Imagine you’re preparing a special dish at home. You gather all the ingredients, tools, and a recipe, and then you package everything in a neat box (container). You take this box to a friend’s kitchen, and it turns out exactly the same as it did at home. No surprises, no missing tools or ingredients. This is what Docker containers do for applications—they ensure the app behaves consistently no matter where it’s run, saving developers time and preventing errors.

Imagine you have an app that you developed on your computer, and it works perfectly. You then give it to a friend or deploy it to a server, but suddenly it starts breaking. The server might have a different operating system, or maybe some important libraries are missing. Docker helps you create a container that has your app, along with everything it needs, so when you run it on any machine, it will behave exactly the same as it did on your computer. It's like packing all the ingredients and tools to bake a cake into a box, so no matter whose kitchen you're in, the cake will turn out the same.

JWT stands for JSON Web Token. It’s a compact, URL-safe token format used to securely transmit information between parties as a JSON object.

How Does JWT Work?

Think of a JWT as a sealed envelope. This envelope contains some information and a signature to make sure it hasn’t been tampered with. Here’s how it works:

1. Header: This part describes how the JWT is encoded and the algorithm used for the signature. It’s like the label on the envelope saying “Here’s how this envelope is sealed.”

2. Payload: This is the main content of the JWT, like the letter inside the envelope. It contains the claims or information you want to share. For example, it might include user information or permissions.

3. Signature: This part is used to verify that the JWT wasn’t altered after it was issued. It’s like the wax seal on the envelope. The server uses a secret key to create the signature, and when you receive the JWT, you can use the same key to check if the envelope has been tampered with.

Example

Here’s a very simplified JWT:

• Header: {"alg": "HS256", "typ": "JWT"}

• Payload: {"id": "1234567890", "name": "John Doe", "message": "this is a secret message"}

• Signature: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

So a JWT might look like this (it’s base64-encoded):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Im5ld3VzZXIiLCJleHAiOjE3MjUxNzQ1MTF9.cue3_U6PCiGCY8RY-kX4Yi-9N5DNT0UbN0mmvTQt5mY

Server: Decode and Verify JWT

If you send the JWT token to the server, the server can extract and read the information in the payload, including id, name, and message, as long as it can verify the token’s signature. Here’s how it works:

1. Receive the JWT: When you send the JWT to the server (usually in the Authorization header or cookies), the server gets the token.

2. Decode the JWT: The server decodes the JWT to read its header and payload. This is possible because JWTs are encoded in Base64, which means the payload is just encoded text. Decoding it doesn’t require a key, but it doesn’t ensure the content hasn’t been tampered with.

3. Verify the Signature: To make sure the JWT hasn’t been altered, the server checks the signature. It uses the same secret key that was used to create the signature. If the signature matches, the server can trust that the payload is valid and hasn’t been modified.

4. Extract Information: Once verified, the server can access the information in the payload, such as id, name, and message, and use it to handle the request appropriately.

Important Points

1. Confidentiality: While JWTs are signed to ensure their integrity, they are not encrypted by default. Anyone who has the JWT can read its payload, so sensitive information should not be included in the payload unless you encrypt the JWT.

2. Expiration: JWTs often include an expiration time (exp claim) to limit their validity period. The server checks this to ensure the JWT is still valid.

Sending & Receiving JWT Token

1. User Sends Payload to Server:

   The user sends a request to the server with their credentials (e.g., username and password) or some other form of data for authentication.

2. Server Generates JWT:

   • The server verifies the user's credentials or payload.

   • If the credentials are valid, the server creates a JWT that includes claims (like id) and signs it using a secret key or a private key (for asymmetric algorithms).

3. Server Sends JWT to User:

   • The server sends the signed JWT back to the user as part of the response.

   • The JWT typically contains a claim (id) that specifies when the token expires.

4. User Saves JWT:

   • The user stores the JWT securely, usually in local storage or a cookie.

   • The JWT can be stored in an HTTP-only cookie to protect it from XSS attacks.

5. User Uses JWT for Further Requests:

   For any subsequent requests to protected resources, the user includes the JWT in the request, typically in the Authorization header like this: Authorization: Bearer <JWT>.

6. Server Verifies JWT:

   • Upon receiving a request with the JWT, the server verifies the token's signature to ensure it hasn’t been tampered with.

   • The server also checks the exp claim to ensure the token hasn’t expired.

   • If the JWT is valid, the server processes the request and sends back the response.

Understanding JWTs and HTTPS Encryption: Why Your JWT Isn’t Encrypted

When dealing with JSON Web Tokens (JWTs), it's crucial to understand how they handle data and the security implications of their use. One common point of confusion is the difference between Base64 encoding, HTTPS encryption, and JWT confidentiality.

Base64 encoding transforms the JWT into a text format that’s easy to transmit, but it’s important to note that Base64 encoding is not encryption. This means that anyone who has access to the JWT can decode it to view its contents.

At the User End

• JWT Readability: On the user end, the JWT is indeed readable. If a user has the JWT (e.g., stored in local storage or cookies), they can decode it to see its contents. However, this assumes the JWT is not encrypted.

At the Server End

• JWT Readability: On the server end, the JWT is also readable. The server decodes the JWT to access its payload (e.g., user ID) after verifying the signature.

The Role of HTTPS: In Transit (During Transmission)

HTTPS (HyperText Transfer Protocol Secure) is designed to protect data transmitted over the internet. Here’s what it does:

• Protection by HTTPS: When the JWT is transmitted over the network (from the client to the server), HTTPS encrypts the entire communication channel. This means:

  • Encryption: HTTPS encrypts the data being sent, including the JWT. So, if someone intercepts the data during transmission, they would see encrypted information and not the actual JWT.

  • Protection: This protects the JWT from being easily read or tampered with by attackers while it's in transit.

Additional Security Measures

If you need to ensure that the contents of the JWT remain confidential, especially if it contains sensitive information, consider the following:

• Avoid Sensitive Data: Refrain from including highly sensitive information directly in the JWT payload.

• Encrypt the JWT: Use additional encryption to protect the JWT’s contents. This ensures that even if the JWT is intercepted or accessed, its payload remains secure.

• Use HTTPS: Always use HTTPS to transmit JWTs over the network to protect the data in transit.

Understanding JWT Expiry and How Servers Handle Expired Tokens

A JWT typically includes an exp (expiry) claim, which specifies the timestamp at which the token will expire. This is usually set when the token is issued. For instance, if a JWT is issued with a 5-minute expiry, it will be valid for 5 minutes from the time of issuance.

Example JWT Payload:

{ "sub": "1234567890", "name": "John Doe", "exp": 1700000000 }

In this example, the exp claim contains a Unix timestamp that represents the expiration time of the token.

What Happens After 5 Minutes?

After the specified expiry time has passed:

1. Token Becomes Invalid: The JWT is no longer valid. This means that any requests made with this token will be rejected by the server.

2. Server Check: When the server receives a request with a JWT, it checks the exp claim to determine if the token has expired.

3. Error Response: If the JWT has expired, the server typically responds with an error message, such as a 401 Unauthorized status, indicating that the token is no longer valid.

How Does the Server Check JWT Expiry?

Here’s how the server determines if a JWT has expired:

1. Receive the JWT: The server receives the JWT from the client, usually in the Authorization header or cookies.

2. Decode the JWT: The server decodes the JWT to access its payload. This decoding allows the server to read the claims, including the exp claim.

3. Extract and Compare exp Claim:

   • The payload contains an exp claim with a Unix timestamp.

   • The server compares the current time with the exp timestamp.

   • If the current time is greater than the exp time, the token is considered expired.

4. Verify Token: In addition to checking the expiry, the server verifies the token’s signature to ensure that the token has not been tampered with.

5. Respond to Client: If the token is expired, the server sends a response indicating that the token is no longer valid.

Secure JWT Storage

JWTs can be stored either on the client side or server side. Each approach has its own security implications and best practices. Here’s a detailed look at both:

1. Client-Side Storage

a. HTTP-Only Cookies

• Description: Storing JWTs in HTTP-only cookies is a highly secure method because these cookies cannot be accessed via JavaScript. This protects against Cross-Site Scripting (XSS) attacks.

• Implementation:

    httpCopy codeSet-Cookie: jwt=your_jwt_token; HttpOnly; Secure; SameSite=Strict
  

  • HttpOnly: Prevents JavaScript from accessing the cookie.

  • Secure: Ensures the cookie is only sent over HTTPS.

  • SameSite=Strict: Limits the cookie to same-site requests, reducing Cross-Site Request Forgery (CSRF) risks.

b. Local Storage

• Description: Local Storage and Session Storage are more accessible via JavaScript, making them vulnerable to XSS attacks.

• Implementation:

    javascriptCopy codelocalStorage.setItem('jwt', your_jwt_token);
  

• Risks: Not recommended due to susceptibility to XSS. HTTP-only cookies are preferred for enhanced security.

2. Server-Side Storage

a. Secure Server-Side Sessions

• Description: Store JWTs on the server side using sessions. This involves storing only a session identifier in a client-side cookie while keeping the actual JWT on the server.

• Implementation:

  • Store the JWT securely in a database or in-memory store like Redis.

  • Store a session ID in an HTTP-only cookie.

  • Map the session ID to the JWT on the server.

b. Token Storage in a Secure Database

• Description: Use a secure database or cache system (e.g., Redis) for storing JWTs, with an identifier (e.g., session ID) in the client-side cookie.

• Implementation:

  • Securely store the JWT in the database or cache.

  • Use a unique identifier to refer to the JWT in client-side cookies.

Preventing Unauthorized Requests

To secure your server and prevent unauthorized access from bots or testing tools, follow these strategies:

1. Rate Limiting:

   • Purpose: Limit the number of requests a client can make within a given timeframe.

   • Implementation: Use middleware or libraries to enforce rate limits on your server.

2. CAPTCHA:

   • Purpose: Verify that the request is made by a human, not a bot.

   • Implementation: Integrate CAPTCHA services like Google reCAPTCHA on critical forms and authentication endpoints.

3. Authentication and Authorization:

   • JWT: Use JWTs to authenticate users and manage access. Ensure JWTs are validated and include necessary claims.

4. Referer and Origin Checking:

   • Purpose: Validate that requests originate from your own website.

   • Implementation: Check the Referer or Origin headers to confirm that requests come from your domain.

5. Secure Development Practices:

   • Regular Audits: Regularly audit your security practices and code.

   • Penetration Testing: Perform penetration testing to identify and address vulnerabilities.

Summary

JWT (JSON Web Token) is a compact token format used to transmit information securely between parties. It consists of three parts:

1. Header: Describes how the JWT is encoded and the signature algorithm used.

2. Payload: Contains the claims or information to be shared.

3. Signature: Ensures the JWT hasn't been tampered with.

How JWT Works:

1. User sends credentials to the server.

2. Server generates a JWT and sends it back to the user.

3. User stores the JWT (commonly in HTTP-only cookies).

4. User includes JWT in requests for protected resources.

5. Server verifies JWT and processes the request if valid.

Key Points:

• JWTs are not encrypted by default; they are encoded. To protect sensitive information, use HTTPS for transmission or encrypt the JWT.

• HTTP-only cookies are preferred for storing JWTs due to their protection against XSS attacks.

• Local Storage is less secure and susceptible to XSS.

• Server-side storage is an option for additional security.

This blog will guide you through setting up an API to access images stored in Amazon S3. We’ll leverage AWS Lambda to create a serverless function that handles image retrieval, and API Gateway to expose this functionality as a RESTful API. To ensure everything works as expected, we'll use Postman for testing and validation.

Step 1: Setting Up The S3 Bucket

1. Open the AWS Management Console and navigate to the S3.

   

2. Click Create Bucket.

3. Give it a suitable name.

   

4. Scroll and click Create Bucket.

5. Open the bucket.

6. Click Upload.

   

7. Click Add files.

   

8. Upload an images.

   Make sure to use smaller images (in kb) for faster access.

Step 2: Creating The Lambda Function

1. Open the Lambda and in AWS Management Console.

   

2. Click Create a function.

3. Give a suitable function name.

4. Select Python 3.8 in Runtime.

   

5. In Advanced settings enable Enable function URL, select NONE in Auth type, and enable Configure cross-origin resource sharing (CORS).

   

   

6. Click on the Create function.

7. Open the function.

8. In the code area paste this code, save it, and click Deploy.

    import base64
    import boto3
   
    s3 = boto3.client('s3')
   
    def lambda_handler(event, context):
        try:
            # Extract bucket name and file name from the event
            bucket_name = event["pathParameters"]["bucket"]
            file_name = event["queryStringParameters"]["file"]
   
            # Fetch the file from S3
            response = s3.get_object(Bucket=bucket_name, Key=file_name)
            file_content = response["Body"].read()
   
            # Return the image as a base64 encoded string
            return {
                "statusCode": 200,
                "headers": {
                    "Content-Type": "image/jpeg",  # Adjust this if you have different image formats
                    "Content-Disposition": f"inline; filename={file_name}"  # 'inline' displays the image in the browser
                },
                "body": base64.b64encode(file_content).decode('utf-8'),
                "isBase64Encoded": True
            }
   
        except s3.exceptions.NoSuchKey:
            # Handle the case where the file does not exist in the bucket
            return {
                "statusCode": 404,
                "body": f"File {file_name} not found in bucket {bucket_name}."
            }
   
        except Exception as e:
            # Handle any other exceptions
            return {
                "statusCode": 500,
                "body": f"An error occurred: {str(e)}"
            }
   

   

9. Now click on Configuration -> Permissions.

10. Click on the Role name, and a new tab will open up.

    

11. Scroll and click Add permissions -> Attach policies.

    

12. Search and select AmazonS3FullAccess then click Add permissions.

    

Step 3: Setting Up API Gateway

1. Open the API Gateway and in AWS Management Console.

   

2. Scroll and click Build on Rest API.

   

3. Select New API and give a suitable name.

   

4. Click on Create API.

5. Open the API.

6. Click on Create resource.

   

7. Give a resource name {bucket}.

   Note: Do not remove the curly bracket it will hold the bucket name which will be sent with the API.

   

8. Click Create resource.

9. Now click on the Create method.

   

10. Select GET for the method type and the Lambda function for the integration type.

    

11. You can enable Lambda proxy integration and select the Lambda function from the drop-down.

    

12. In the Method request settings, select Validate query string parameters and headers under Request validator.

    

13. In URL query string parameters click Add query string, type file under Name, and check Required.

    

14. Click Create method.

15. From the left navigation panel click API settings.

16. Click on Manage media types.

    

17. Then click on Add binary media types.

    

18. Enter */* and click on Save changes.

    

19. From the left navigation panel click Resources.

20. Click on Deploy API.

    

21. Select *New Satge* and give a suitable name.

22. Click on Deploy.

23. From the left navigation panel click Stages.

24. Click on + until to see GET then click on GET.

    

25. Copy the Invoke URL.

Step 4: Testing the API with Postman

1. Open Postman.

2. Paste the link and replace {bucket} with the you s3 bucket name and add ?file=file_name. Replace file_name with the file name that you upload in the s3 bucket (Example: if the URL is https://url.com, the s3 bucket name is images.xyz, and the file name is maths.jpg then use the link https://url.com/images.xyz?file=maths.jpg)

3. Click Send and you can see the file in Body section.

   You can also use this link in a browser tab and fetch the image.

   

   

Step 1: Creating a S3 Bucket

1. Open the AWS Management Console and navigate to the S3.

   

2. Click Create Bucket.

3. Give it a suitable name.

   

4. Scroll and click Create Bucket.

   

5. Copy the following and create an index.html file.

    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Demo Website</title>
    </head>
    <body>
        <div class="container">
            <h1>You're truly welcome!</h1>
            <h2>Do like the Blog if you find the tutorial helpful.</h2>
            <ul class="social-links">
                <li><a href="https://arishahmad.hashnode.dev/hosting-your-serverless-website-using-aws" target="_blank">Blog</a></li>
            </ul>
            <h3 id="views">Views</h3>
        </div>
        <script src="script.js"></script>
    </body>
    </html>
   

6. Upload this file in the S3 bucket.

Step 2: Creating CloudFront distribution.

1. Navigate to CloudFront in the AWS Management Console.

   

2. Click Create a CloudFront distribution.

3. Select the S3 bucket you just created under the Origin domain.

   

4. Under Origin access click Origin access control settings.

5. Click Create new OAC -> Create.

   

6. Under Web Application Firewall (WAF) select Do not enable security protections.

   

7. Scroll and click Create distribution.

   This screen will pop up.

   

8. Click Copy policy.

   If the Copy policy option doesn't appear.

   1. Open the distribution.

   2. Click on Origins.

      

   3. Select the origin and click Edit.

   4. Scroll and click Copy policy.

      

Step 3: Updating S3 bucket policy

1. Navigate to S3 in the AWS Management Console.

2. Open the bucket.

3. Click on Permissions.

   

4. On Bucket policy click Edit.

   

5. Paste the policy and click Save changes.

Step 4: Set up Route53

1. Navigate to Route 53 Dashboard in the AWS Management Console.

   

2. Click Create hosted zone.

3. Enter the Domain name.

4. Select Public hosted zone under Type.

5. Scroll and click Create hosted zone.

6. Select the record with NS type, Record details will open up.

7. Copy each value of this record and add this to the Nameserver. This option will be provided by the platform where you bought the domain.

Step 5: Editing the CloudFront

1. Open the CloudFront distribution.

2. Select the distribution and Click Edit on Settings.

   

3. Select Add items under Alternate domain name (CNAME).

   

4. Enter the domain on which you want to host the website (Example: If your domain name is example.com then enter demo.example.com).

   

5. Scroll and click Request certificate. A new tab will open up.

6. Click Next.

   

7. Enter .<your domain name> (Example: If your domain name is example.com, enter *.example.com).

8. Scroll and click Request.

   Your new certificate might continue to display a status of Pending validation for up to 30 minutes.

9. Open the Certificate.

10. Click Create records in Route 53.

    

11. Click Create records.

    

    You can check the new route must be added in the hosted zone.

    Now wait till the status of certificate is not Issued.

12. Go back to the CloudFront tab, and select the newly created Custom SSL certificate.

13. Enter index.html under the Default root object.

14. Scroll and click Save changes.

Step 6: Create a record in the Hosted Zone.

1. Open the hosted zone in Route53.

2. Click Create record.

   

3. In record name enter the subdomain. This should be same as the alternate domain name you entered in the CloudFront distribution.

4. Enable the Alias.

5. Choose Alias to CloudFront distribution and select the distribution you created.

6. Click Create Record.

   

7. Now visit the alternate domain name, and you will see the hosted website. This might take few minutes until the CloudFront distribution is ready.

Step 7: Set up the DynamoDB

1. Navigate to DynamoDB in the AWS Management Console.

   

2. Click Create table.

3. Enter a suitable name.

4. Endet id in Partition key.

   

5. Scroll and click Create Table.

6. Select the table, go to Actions -> Explore items.

   

7. Click Create item.

8. Enter value 0 in id Attribute.

9. Select Add new attribute -> Number.

10. Enter the Attribute name as views and enter value 0.

11. Click Create item.

Step 8: Create the Lambda Function

1. Navigate to AWS Lambda in the AWS Management Console.

   

2. Click Create a function.

3. Enter a suitable Function name.

4. Select Python 3.8 in Runtime.

   

5. Select Create a new role with basic Lambda permissions in the Execution role.

   

6. In Advanced settings click Enable function URL and NONE in Auth Type.

7. Check the Configure cross-origin resource sharing (CORS).

   

8. Scroll and click the Create function.

9. Copy the following code.

    import json
    import boto3
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('demo-table')
    def lambda_handler(event, context):
        response = table.get_item(Key={
            'id':'0'
        })
        views = response['Item']['views']
        views = views + 1
   
        print(views)
   
        response = table.put_item(Item={
            'id':'0',
            'views': views
        })
   
        return views
   

10. Paste this file in the code area.

    Note: Change the table name in this file.

    

11. Save the file then Click Deploy.

12. Click Configuration -> Permissions.

    

13. Click on the role, a new tab will open up.

14. Click Addpermissions -> Attach policies.

    

15. Search and select AmazonDynamoDBFullAccess.

    

16. Click Add permissions.

17. Now Come back to the Lambda tab.

18. Click Code and then click Test.

    

19. Enter a suitable name, then click Save.

20. Now click Test again, and you can see the response.

Step 9: Creating the JS file

1. Copy the following code.

    let counter = document.getElementById("views");
   
    async function updateCounter() {
        try {
            let response = await fetch("lambda_function_url");
            if (!response.ok) {
                throw new Error('Network response was not ok');
            }
            let data = await response.json();
            console.log(data);
            counter.innerHTML = `Views: ${data}`;
        } catch (error) {
            console.error('Failed to fetch data:', error);
            counter.innerHTML = 'Failed to load views';
        }
    }
   
    updateCounter();
   

2. Create a file named script.js file, and paste the code.

3. Copy the Lambda function URL and replace lambda_function_url in the file with the URL.

   

4. Now upload this script.js file in the S3 bucket.

Step 10: Finishing Up

Visit the Alternate domain name you entered in the CloudFront. You can see the hosted website and with each reload the view counter will increase. You can also check the increased value of views in the dynamoDB.

If the changes are not visible you may need to create an Invalidation.

1. Open the CloudFront distribution you created.

2. Click Invalidations -> Create invalidation.

   

3. Type /* and click Create invalidation.

4. Wait while the status is in progress.

5. Reload the website, and you'll be able to see the changes.

You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. AWS supports six types of policies: identity-based policies, resource-based policies, permissions boundaries, Organizations SCPs, ACLs, and session policies.

For more details visit.

Create IAM Policies

1. Open the AWS Management Console and navigate to the Identity and Access Management (IAM).

2. Click on Policies from the left navigation panel.

3. Click Create policy.

   

4. Choose S3 from the down under Service.

   

   

5. Click All list actions under Access level.

   

6. Select All under Resources.

   

7. Click Next.

8. Write a suitable policy name.

   

9. Click Create policy.

Creating and attaching policy with an IAM user

1. Click on Users from the left navigation panel.

2. Click Create user.

   

3. Write a suitable user name.

4. Check Provide user access to the AWS Management Console.

   

5. Select I want to create an IAM user.

6. Click Custom password and type a suitable password.

   

7. Uncheck Users must create a new password at next sign-in for now.

   

8. Click Next.

9. Select Attach policies directly.

10. Search and select the newly created policy.

    

11. Click Next -> Create user.

12. Create an S3 bucket.

13. Login as an IAM user with newly created credentials.

14. The S3 bucket can be viewed by this IAM user.

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

For more details visit.

Creating IAM Roles

1. Open the AWS Management Console and navigate to the Identity and Access Management (IAM).

2. Click on Roles from the left navigation panel.

   

3. Click Create role.

4. Select AWS Service.

   

5. Select EC2 in the Use case.

   

6. Click Next.

7. Search AmazonS3FullAccess in Permissions policies, and select it.

   

8. Write a suitable role name.

9. 

   Click Next -> Create Role.

10. Open the role by clicking on its name.

11. Select Permissions, under Permissions policies you can check the policy names.

Attaching role to a service

1. Create an EC2 instance.

2. Select the instance.

3. Go to Actions -> Security -> Modify IAM role.

   

4. Select the IAM role from the from down.

   

5. Click Update IAM role.

1. Open the AWS Management Console and navigate to the Identity and Access Management (IAM).

2. Create 2-3 users, you can use Creating And Assigning Policy to IAM Users.

3. Click on User groups from the left navigation panel.

4. Click Create group.

   

5. Write a suitable name.

6. You can select all the users you want to add to this group.

   

7. Search and check the policies you want to assign (Eg. AmazonEC2ReadOnlyAccess).

8. Click Create user group.

9. Now open the user and go to Permissions, you can check the policies given under Permissions policies.

   

Adding users to multiple User Groups

1. Create another user group and add the same users that were added in the previous user group.

2. Search and select some other policies from the previous one (Eg. AmazonEC2ReadOnlyAccess).

3. Now open the user and go to Permissions, you can check the policies from different user groups given under Permissions policies.

   

Giving permissions to a specific user

1. Open the user.

2. Under Permissions, click Add permissions -> Add permissions.

   

3. Select Attach policies directly.

   

4. Search and select any policy (Eg. AmazonDynamoDBFullAccess).

5. Click Next -> Add permissions.

To check, open the user under Permissions and check the newly added permission.

Copy permission to a user

1. Create a new user.

2. Open this user.

3. Under Permissions, click Add permissions -> Add permissions.

4. Click Copy permissions.

   

5. Select any user whose permissions are needed to be copied.

   

6. Click Next -> Add permissions.

7. Now open this user, and click Permissions, under Permissions policies you can check all the permissions given to this user which were given to the user from which the permissions are copied.

   

To manage your objects so that they're stored cost effectively throughout their lifecycle, create an Amazon S3 Lifecycle configuration. An Amazon S3 Lifecycle configuration is a set of rules that define actions that Amazon S3 applies to a group of objects. For more information visit.

Steps to Create an S3 Lifecycle

1. Open the AWS Management Console and navigate to the S3 dashboard.

2. Click Create bucket.

   

3. Select General purpose bucket type.

   

4. Write a bucket name, this name must be globally unique.

   

5. Select ACLs enabled Object Ownership.

6. Uncheck Block all public access -> Check the Acknowledgement.

   

7. Enable Bucket Versioning.

   

8. Click Create bucket.

9. Click on Management.

   

10. Click on the Create lifecycle rule.

11. Write a suitable name.

12. Select Apply to all the objects in the bucket under Choose a rule scope.

    

13. Under Lifecycle rule actions select Move current versions of objects between storage classes.

    

14. Under Transition current versions of objects between storage classes, In Choose storage class transitions each class has minimum storage duration.

    The Days after object creation should match these minimum duration periods.

    All the duration period with there classes will be shown in the drop down. Add the required number of transitions. Then check the acknowledgement.

    

15. Click Create rule.

16. To delete the rule, select the rule -> Delete -> Delete.

    

    

S3 Object Lock can help prevent Amazon S3 objects from being deleted or overwritten for a fixed amount of time or indefinitely. Object Lock uses a write-once-read-many (WORM) model to store objects. You can use Object Lock to help meet regulatory requirements that require WORM storage, or to add another layer of protection against object changes or deletion.

Object Lock provides two ways to manage object retention: retention periods and legal holds. An object version can have a retention period, a legal hold, or both.

• Retention period – A retention period specifies a fixed period of time during which an object remains locked. You can set a unique retention period for individual objects.

• Legal hold – A legal hold provides the same protection as a retention period, but it has no expiration date. Instead, a legal hold remains in place until you explicitly remove it. Legal holds are independent from retention periods and are placed on individual object versions.

Object Lock works only in buckets that have S3 Versioning enabled. When you lock an object version, Amazon S3 stores the lock information in the metadata for that object version. Placing a retention period or a legal hold on an object protects only the version that's specified in the request. Retention periods and legal holds don't prevent new versions of the object from being created, or delete markers to be added on top of the object. For information about S3 Versioning, see Using versioning in S3 buckets.

If you put an object into a bucket that already contains an existing protected object with the same object key name, Amazon S3 creates a new version of that object. The existing protected version of the object remains locked according to its retention configuration.

Steps for Object Lock in Amazon S3

1. Open the AWS Management Console and navigate to the S3 dashboard.

2. Click Create bucket.

   

3. Select General purpose bucket type.

   

4. Write a bucket name, this name must be globally unique.

   

5. Select ACLs enabledObject Ownership.

6. Uncheck Block all public access -> Check the Acknowledgement.

   

7. Enable Bucket Versioning.

   

8. Under Additional setting, enable Object Lock.

   

9. Click Create bucket.

10. Open the newly created bucket by clicking on its name.

11. Click Properties.

    

12. Scroll and click Edit on Object Lock.

    

13. Enable Default retention, set Default retention mode to Governance, and set Default retention period to 1 Days.

    Governance: Users with specific IAM permissions can overwrite or delete protected object versions during the retention period.

    Compliance: No users can overwrite or delete protected object versions during the retention period.

    

14. Click Save changes.

15. Now Click on Objects.

16. Click Upload.

    

17. Now click on Add files.

    

18. Select any file you want to upload.

19. Scroll and click Upload.

20. Select the file and permanently delete the file. You'll see the file is permanently deleted. The reason for this is that the file is in Governance lock.

    Note: Make sure Show Versions is enabled while you delete the file. If it is not, while will not be permanently deleted.

    

21. Now upload the file again.

22. Open the file by clicking on its name.

23. Under Properties, Edit Object Lock retention.

    

24. Set Retention mode to Compliance mode.

    Note: You'll not be able to delete the file before the retention period.

    

25. Click Save Changes.

26. Now select the object and try to permanently delete the file. You'll get an error when you try. Wait until the retention period is over, then you will be able to delete it.

1. S3 stands for Simple Storage Service.

2. Amazon S3 is an object storage service that offers industry-leading scalability, data availability, security, and performance.

3. Store and protect any amount of data for a range of use cases, such as data lakes, websites, cloud-native applications, backups, archive, machine learning, and analytics.

4. Amazon S3 is designed for 99.999999999% (11 9's) of durability, and stores data for millions of customers all around the world.

Steps to Create an S3 Bucket

1. Open the AWS Management Console and navigate to the S3 dashboard.

2. Click Create bucket.

   

3. Select General purpose bucket type.

   

4. Write a bucket name, this name must be globally unique.

   

5. Select ACLs disabled under Object Ownership.

   

6. Leave the Block all public access checked.

7. Set Bucket Versioning disabled.

8. Click Create bucket.

9. Open the newly created bucket by clicking on its name.

   

10. Click Upload.

    

11. Now click on Add files.

    

12. Select any file you want to upload, preferably a text file.

13. Scroll and click Upload.

14. Select the file -> Actions -> Download As -> Click on the file name, A new tab will open and download will start -> Close.

15. Now Select the file -> Click Copy URL. -> Paste in a new browser tab, Unfortunately, you won't be able to view the file.

16. Now Select the file -> Click Open, File will open up in a new tab.

17. You can see the file can be accessed only by this account and no one else can access it.

18. To make the Object's URL publically available -> Select the bucket -> Make public using ACL, this option must be disabled because we disabled ACLs in step 6.

19. To change it Go to permission.

    

20. Click Edit on Block public access (bucket settings) -> Uncheck Block all public access -> Save changes -> type confirm -> Confirm.

    

    

21. Click Edit on Bucket Ownership -> ACLs enabled -> Check the acknowledgement -> Save changes.

    

22. Now go back to Objects.

23. Select the object -> Actions -> Make public ACL -> Make Public.

24. Now select the object -> Copy URL -> Paste it into another tab, and the file should open.

25. To delete the object, select the object ->Click Delete -> type permanently delete -> Click Delete Objects.

26. To delete the bucket, select the bucket -> Click Delete -> type the bucket name -> Click Delete bucket.

Load balancing is the method of distributing network traffic equally across a pool of resources that support an application. Modern applications must process millions of users simultaneously and return the correct text, videos, images, and other data to each user in a fast and reliable manner. To handle such high volumes of traffic, most applications have many resource servers with duplicate data between them. A load balancer is a device that sits between the user and the server group and acts as an invisible facilitator, ensuring that all resource servers are used equally.

Steps to create an application load balancer

1. Open the AWS Management Console and navigate to the EC2 dashboard.

2. Create an instance and host a website, you can use an EC2 instance with Windows or an EC2 instance with Linux.

   NOTE: While launching the instance, increase the number of instances to the desired amount.

   

3. Connect to each of these instances and host the website.

4. In the left navigation panel, choose Load Balancers under Load Balancing.

5. Click on Create load balancer.

   

6. Under Application Load Balancer click Create.

7. Give a suitable Load balancer name.

8. Select the desired Availability Zone under Mappings.

   

9. Under Listeners and routing click Create target group. A new tab will open up.

   

10. Choose a target type, Instances.

11. Type a suitable Target group name.

12. Click Next.

13. Select the instances with which you want to make a load balancer.

14. Scroll and click on Include as pending below.

15. Click Create target group.

16. Please go ahead and return to the previous tab.

17. Refresh the default action.

18. Now select the newly created target group from the drop down.

19. Scroll and click Create load balancer.

20. Wait while the status is not Active.

21. Now copy the DNS Name to access the hosted website.

    The website will be accessed from any of the instances previously created.

    

    22. To delete the Load balancers, select the load balancer -> Click Actions -> Delete load balancer -> type confirm -> Delete.

    23. To delete the Target group, select the target group -> Click Actions -> Delete -> Click Yes, delete

AWS Auto Scaling monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost. Using AWS Auto Scaling, it’s easy to setup application scaling for multiple resources across multiple services in minutes.

Horizontal auto scaling in AWS is a way to scale a system by adding more machines or servers to an auto scaling group.

Follow these steps to horizontally auto scale an AWS web application

1. Open the AWS Management Console and navigate to the EC2 dashboard.

2. Create an instance and host a website, you can use an EC2 instance with Windows or an EC2 instance with Linux.

3. Create an Image of this instance, you can use Create AMIs from EC2 Instances.

4. In the left navigation panel, choose Auto Scaling Groups under Auto Scaling.

5. Click Create Auto Scaling group.

6. 

   Write a suitable name for the Auto scaling group.

7. Scroll down and click Create a launch template. A new tab will open up.

8. Write a suitable name for the template.

9. Scroll and click on My AMIs under Application and OS Images (Amazon Machine Image).

10. 

    Select the newly created AMI.

11. Select any free tier instance type (Example: t2.micro).

12. Select any Key pair.

13. Select any Security group under Network settings

14. Now click on Create the launch template.

15. Please go ahead and return to the previous tab and refresh the launch template.

16. Now you can select the newly created launch template from the drop-down.

    

17. Click Next.

18. Under Network select all the availability zones in which you want your instances.

19. Now click Next.

20. Scroll and hit Next.

21. Under the Group Size set Desired capacity to 3.

    Desired capacity: Represents the initial capacity of the Auto Scaling group at the time of creation. An Auto Scaling group attempts to maintain the desired capacity. It starts by launching the number of instances that are specified for the desired capacity, and maintains this number of instances as long as there are no scaling policies or scheduled actions attached to the Auto Scaling group.

22. Under Scaling set Min desired capacity to 2 and Max desired capacity to 5.

    Minimum desired capacity: This represents the minimum group size. When scaling policies are set, they cannot decrease the group's desired capacity lower than the minimum capacity.

    Maximum desired capacity: Represents the maximum group size. When scaling policies are set, they cannot increase the group's desired capacity higher than the maximum capacity.

23. Now click on the Target tracking scaling policy.

    

24. Now scroll and hit Next.

25. Now click Next -> Next.

26. Review all the changes made.

27. Click on Create auto scaling group.

28. You can go to the instances to check the creation on the EC2 instance with the same hosted website. To check, hit the Public IPv4 address of all the new instances.

29. To delete the auto-scaling group, select the group -> Actions -> Delete -> type delete -> Delete.

    

30. To delete the template, select the launch template -> Actions -> Delete template -> type delete -> Delete.