Forem: Parul Chaddha

Scalability Trade-offs

Parul Chaddha — Tue, 01 Jul 2025 19:46:40 +0000

Ever wondered what happens when your side project goes viral overnight? You get thousands of users in an hour, and suddenly… your website crashes. It’s slow. Things break. And people leave.

Why? Because your system wasn’t scalable.

In this blog, I’ll break down scalability in a super simple way — no heavy jargon, just the real stuff you need to know if you're a developer, builder, or someone curious about how apps like Instagram or Amazon handle millions of users without falling apart.

📌 What Is Scalability?

In simple terms:

Scalability is the ability of a system to handle increased load — whether it’s more users, more data, or more traffic — without breaking, crashing, or slowing down.

So when we say “this app scales well,” we mean:

“It still works smoothly, even if a lot more people start using it.”

⚙️ Is Scalability About Coding or Hardware?

Here’s the truth — it’s both.

✅ Good code helps your system stay efficient.
✅ Right infrastructure helps your system stay alive when traffic grows.
✅ Smart architecture decides how easily you can grow.

You can't throw better hardware at bad design and expect miracles. You need both working together.

🧠 Types of Scalability

There are two ways to scale a system:

1. Vertical Scalability (Scaling Up)

This means upgrading your existing server:

Add more RAM
Use faster CPU
Better disk speed

📦 Think of it like upgrading your laptop — same machine, just more powerful.

✅ Simple

❌ There’s a limit — you can’t upgrade forever

2. Horizontal Scalability (Scaling Out)

This means adding more servers to share the load.

📦 Think of it like hiring more chefs when your restaurant gets too many orders.

✅ Flexible, preferred for large-scale systems

❌ More complex — needs load balancers and distributed systems design

🛑 How Do You Know a System Is Not Scalable?

Here are some red flags:

⏳ Slows down when users increase
💥 Crashes under load
🐌 Delayed responses
🔄 Features stop working randomly
🔗 One service’s failure brings everything down

If your app works fine with 100 users but misbehaves with 500, you’ve hit a scalability issue.

🛠️ How Do You Build a Scalable System?

Let’s get to the good part — what actually makes a system scalable?

1. Design Stateless Services

Don’t tie user sessions to a single server. Use something like Redis to manage sessions.

📌 Why? It allows you to spin up more servers easily.

2. Use Load Balancers

When you have multiple backend servers, a load balancer sits in front and distributes traffic.

📌 Think of it like a receptionist assigning customers to different counters.

3. Use Caching

Not every request needs to hit the database.

Use tools like:

Redis or Memcached for server-side caching
CDNs (like Cloudflare) for static files

📌 It’s like keeping a copy of frequently used books near your desk instead of walking to the library each time.

4. Decouple Services

Break your application into microservices or at least modular services.

📌 Benefit? You can scale only the part that needs it. For example, scale your payment service without touching user profiles.

5. Use Asynchronous Processing

Not every task needs to be done immediately.

Use queues like:

Kafka
RabbitMQ
AWS SQS

📌 For example: After a user uploads a video, process it in the background — don’t make them wait.

6. Scale Your Database

This is often the bottleneck. You can:

Add replication (copies of data)
Use sharding (split data across DBs)
Choose NoSQL (MongoDB, Cassandra) if data is unstructured

7. Monitor Everything

If you can’t measure it, you can’t fix it.

Use tools like:

Prometheus + Grafana
Datadog
New Relic

📌 Watch CPU, memory, DB response time, and API failures.

8. Auto-Scaling & Cloud Infrastructure

Cloud platforms (AWS, GCP, Azure) let you scale based on demand.

📌 Example: Auto-add a server if CPU usage crosses 80%.

Use containerization (Docker) and orchestration (Kubernetes) for scalable deployments.

💡 Real-Life Analogy: The Coffee Shop

Imagine you own a coffee shop:

You have 1 barista. All good.
Then 100 people walk in together.

If:

The barista panics and messes up orders — not scalable
You bring in 5 more baristas and assign one to each counter — scalable

Same logic applies to apps.

🔍 Real-World Example

Let’s say you’ve built a resume analysis tool (just an example):

Day 1:

1 backend server
Local file storage
No queue — everything sync

Week 1: Gets 5k users a day

App slows down
File uploads hang
DB gets jammed

Fix:

Use Amazon S3 for resume storage
Use Redis to cache past results
Add background processing for PDF parsing
Horizontal scaling with Docker containers

Boom — now your system can handle 100k users/day.

Consistency Patterns

Parul Chaddha — Fri, 04 Apr 2025 21:52:08 +0000

If you’ve ever built or worked with a distributed system, you’ve probably asked:

“How do I keep all my data in sync when it’s scattered across multiple servers?”

Well, that’s where consistency patterns come in.

First, What’s a Distributed System?

A distributed system is basically a bunch of components running on different networked computers, all working together to achieve a common goal. Think of it as teamwork—each part plays its role, and together, they build something powerful.

Example:

In an e-commerce app, you might have:

An account service
A payment service
An order service
An inventory service
A loyalty points service

When a user buys a book, multiple services kick in. So how do we make sure they’re all on the same page (literally)? That’s where data consistency becomes critical.

Why Does Consistency Matter?

Let’s say two users try to buy the same last-copy book at the same time.

If the inventory doesn’t update fast enough after the first order, both users might think the book is available. You can guess how that ends—not good for customer trust.

Meet the Consistency Patterns

There are three major patterns that define how data is kept consistent in distributed systems:

1. Strong Consistency

Every read reflects the most recent write.
All data copies are updated synchronously.
You always see the latest state—no surprises.

Example:

A banking system where a fund transfer must reflect immediately on both accounts. No delays, no stale data. Accuracy over speed.

Pros: High data integrity

Cons: Higher latency, lower availability

2. Weak Consistency

Reads may or may not reflect recent writes.
Data may be inconsistent across nodes.
Great for systems where speed matters more than precision.

Example:

In online multiplayer games, actions might appear instantly to nearby players but lag for others if there’s network delay.

Pros: High availability, low latency

Cons: Risk of data conflicts

3. Eventual Consistency

A flavor of weak consistency—but with a promise.
Eventually, all nodes will reflect the latest data.
Updates are propagated asynchronously.

Example:

A social media post shows up instantly for users in the same data center, but may take a few seconds to appear globally.

Pros: Good balance between availability and consistency

Cons: Temporary inconsistencies

So, Which Pattern Should You Choose?

It depends on what your system needs:

Strong Consistency → Use when accuracy is non-negotiable (e.g., finance).
Weak Consistency → Use when speed is crucial and some delay is acceptable (e.g., games).
Eventual Consistency → Use when you want scalability and availability, but can tolerate slight delays (e.g., social platforms).

CAP Theorem

Parul Chaddha — Thu, 03 Apr 2025 20:34:02 +0000

Let’s start with a truth that hits every backend engineer eventually:

Scaling your system will make your life more complicated.

In today’s world of growing traffic, real-time apps, and microservices, we’re all striving to make our systems bigger, faster, and more resilient. And sure, throwing in extra hardware sounds like an easy fix—just add more servers, more storage, more compute. Problem solved, right?

Not quite.

The more we scale out—adding more machines to distribute the load—the more we have to deal with the complexity that comes with distributed systems. And that’s exactly where the CAP Theorem becomes your new best friend (or worst enemy, depending on how well you understand it).

So, What Is the CAP Theorem?

The CAP Theorem is a principle that applies to distributed systems—those magical systems made of multiple nodes talking to each other across a network.

It states that in the event of a network partition, a distributed system can only guarantee two out of the following three properties:

Consistency – Every read receives the most recent write.
Availability – Every request receives a (non-error) response, even if it's not the latest data.
Partition Tolerance – The system continues to operate even if parts of the network can't communicate.

And here’s the kicker: you must choose two. You can’t have all three. Not during a network partition.

Let that sink in..........

Quick Definitions Before We Dive Deeper

Consistency means that if you write a value to the system, all future reads return that same value—no surprises.
Availability means that every request receives some kind of response—success or stale data, but never a timeout or failure.
Partition Tolerance means your system still works even if some nodes can’t talk to others. Because guess what? Networks fail. Regularly....

Reality Check: Networks Are Not Reliable

We don’t live in a perfect world where all nodes stay connected forever.

Servers crash.
Routers drop packets.
Data centers get disconnected.

You don’t get to pick if a network partition will happen—you only choose how to respond when it does.

And that’s where the CAP Theorem becomes more than just a theoretical concept. It becomes a design decision.

The Real Trade-Off: CP vs AP (Because P Is Non-Negotiable)

Since Partition Tolerance is not optional in the real world, you’re left with two architectural styles:

1. CP – Consistency + Partition Tolerance

In this setup, the system sacrifices Availability during a partition.

If two nodes can’t talk to each other, you may:

Wait for the partitioned node to respond (could be a timeout),
Or return an error.

Why would you do this?

Because your application can’t afford stale data. Think:

Banking transactions
Inventory management
Medical systems

When correctness is critical, you choose consistency.

2. AP – Availability + Partition Tolerance

Now we flip it.

In this model, the system remains Available, even during partitions. But it may return:

Slightly outdated data
Temporary inconsistencies

Why would this make sense?

Because your app needs to stay online, even if some data is stale. Think:

Shopping carts
Social media feeds
Streaming platforms

When user experience and uptime matter more than perfectly fresh data, you prioritize availability.

This Is a Software Trade-Off—You’re in Control

Here’s the good news: you get to decide how your system behaves when things go sideways.

Want to pause all writes during a partition to ensure consistency? Go CP.

Want to accept all writes and resolve conflicts later? Go AP.

This decision depends entirely on your application’s requirements. But here’s what’s non-negotiable:

Network partitions will happen. Prepare for it.

Final Thoughts: Why the CAP Theorem Matters

Building distributed systems gives you scale, speed, and flexibility. But it also brings complexity and trade-offs.

Understanding the CAP Theorem is essential because it helps you design systems that behave predictably when the unpredictable happens.

Mess this up, and your app may fail the moment you hit real-world traffic.

Get it right, and you’ve built a foundation that can scale with confidence.

So the next time you're designing a distributed system, ask yourself:

Can I tolerate stale data?
Do I need every request to succeed?
How critical is consistency for my users?

And remember: you can’t cheat the CAP Theorem, but you can play it smart.

Latency v/s Throughput – What’s Slowing You Down?

Parul Chaddha — Thu, 03 Apr 2025 04:57:05 +0000

Ever waited for a web page to load and felt like time had slowed to a crawl? Or noticed your internet blazing fast while streaming but struggling during a video call?

Let’s explore why that happens.

Two core metrics drive system performance: latency and throughput. They might sound similar, but they measure very different things. By the end of this post, you’ll understand what they are, how they relate, and how they impact real-world systems.

What is Latency?

Let’s say you click a button. How long does it take before something happens?

That delay is latency—the time between a request and its corresponding response.

Latency is typically measured in milliseconds (ms) or microseconds (µs), and it reflects how fast a system can respond to a single task. The lower the latency, the faster and more responsive the system feels.

What Causes Latency?

Network travel time (especially across multiple hops)
Network congestion
Complex or inefficient algorithms
Server or hardware load
Disk or memory speed

High latency often results in slow performance. Low latency, on the other hand, makes applications feel snappy and responsive.

What is Throughput?

While latency is about the speed of a single task, throughput measures the system’s capacity—how many tasks it can complete in a given time.

Throughput is measured in:

Requests per second (RPS)
Transactions per second (TPS)
Bits per second (bps)

A high-throughput system can process large volumes of data or requests efficiently. A low-throughput system, even if fast for one user, will struggle when handling many simultaneous users.

What Limits Throughput?

Hardware capacity (CPU, memory, disk I/O)
Network bandwidth
Software design and architecture
Algorithm efficiency
Concurrency and thread management

Throughput matters when evaluating systems under load—like web servers, databases, and networks.

Latency vs Throughput – What’s the Difference?

Think of a toll booth:

Latency is how long it takes for one car to pass through.
Throughput is how many cars can pass through per minute.

You can have:

Low latency but low throughput (fast for one, but not for many)
High throughput but high latency (handles volume, but slowly)
The ideal: low latency and high throughput (fast and scalable)

In system design, optimizing one often affects the other, which brings us to the trade-offs.

Real-World Example: Web Servers

Imagine you're running a web server and want web pages to load quickly (low latency) while also serving thousands of users (high throughput).

Option 1: Add More Servers

Adding more servers increases throughput by handling more requests in parallel. But latency might increase due to routing overhead or data replication across multiple servers.

Option 2: Optimize Server Code

Making the server software more efficient increases throughput per server. But if it uses more resources to serve requests, individual response time may increase, raising latency.

The solution often involves:

Load balancing
Caching
Smart request routing

These techniques help balance both latency and throughput.

Real-World Example: Databases

In databases, tuning for latency might mean caching frequently accessed data in memory. This allows for near-instant data retrieval.

However, relying too much on memory can reduce the system's throughput, as less memory is available for other operations.

Alternatively, optimizing for throughput might mean batch processing large amounts of data—efficient overall, but slower for individual queries, increasing latency.

So, Which One Should You Optimize?

It depends on your use case.

The general goal in system design is:

Maximize throughput while maintaining acceptable latency.

If your system is blazing fast for one user but chokes with ten, it’s not scalable.

If it handles thousands of users but each request takes 5 seconds, it’s not usable.

Final Thoughts

Latency and throughput are both critical, but they serve different purposes.

Latency measures responsiveness.
Throughput measures capacity.

Understanding how they interact helps you make smarter system design decisions. Whether you're working on web apps, APIs, databases, or networks—knowing when to optimize for one or balance both can make or break your system's performance.

Scalability v/s Performance

Parul Chaddha — Wed, 02 Apr 2025 19:10:14 +0000

Have you ever found yourself waiting in a long checkout line at your local supermarket? That everyday experience is a lot like the challenge of balancing performance and scalability in software development.

Understanding the Basics

Early in my career, I mistakenly thought that performance and scalability were one and the same.

Imagine my surprise when my very first project to scale a system ended up making my code run slower—in my development environment, at least!

Let’s break it down:

Performance is all about speed. It’s how fast your system processes a single request.
Scalability is about handling growth—more users, more data, more traffic—while keeping performance steady.

While the speed of light remains constant, software speed? Not so much.

The Supermarket Analogy

Picture a supermarket with a single cashier who checks out one shopper every minute.

When just one shopper comes in, everything is smooth.
But what happens when two shoppers arrive every minute?

Here’s what it looks like:

1st shopper: Checked out in 1 minute.
2nd shopper: Waits 1 minute → Checkout = 2 minutes.
3rd & 4th shoppers: Each one waits even longer.
Eventually, the wait time balloons as more shoppers arrive.

So what’s happening here?

The performance of one cashier is fine under low traffic, but once the flow increases, performance drops rapidly.

Scalability to the Rescue

Scalability ensures that the system maintains consistent performance even as traffic increases.

This might mean building more complex systems that seem "slower" when things are quiet—but the trade-off is worth it when you're handling real traffic.

For example, adding more cashiers in our supermarket:

Might take slightly longer for a single shopper.
But allows the system to handle many more shoppers efficiently.

Tactics for Better Scalability

1. Caching

Let’s say regulars buy the same items every day.

Instead of scanning each item again and again, we give them a special receipt. Scanning this receipt takes 10 seconds, not 1 full minute.

Boom. One cashier now checks out 6 people per minute instead of 1.

But of course, caching isn’t perfect. Sometimes the receipt (cache) fails:

The shopper’s items change daily.
It’s a new shopper with no receipt.
The receipt (cache) is lost.

These are cache misses, and they might make things even slower (e.g., 1 min 10 sec instead of 1 min).

2. Adding More Cashiers

More cashiers = more people served.

But there’s still complexity:

Shoppers might spend time deciding which cashier to approach.
If one cashier is slow or gets sick, lines get messed up.
Space becomes an issue as lines grow.
People might cut the line, causing frustration (and maybe chaos 😅).

3. Single Queue Strategy

So what’s a better solution? A single, shared queue.

Shoppers line up in one line.
They go to the next available cashier.
No worrying about being stuck behind a slowpoke.
No panic if a cashier disappears.

Yes, the shopper might have to walk a little farther, but overall, fairness and efficiency win.

In the world of software, this is like using a message queue.

Each shopper = a message
Cashiers = worker processes
Queue = a place to manage load evenly

Wrapping It Up

Balancing performance and scalability is a lot like managing a busy supermarket.

Don’t panic if your code slows down a bit after scaling—it’s expected.
Focus on the big picture: Can your system handle growth without breaking?

Happy scaling, and may your code run fast—even when the line is long!

Introduction to System Design

Parul Chaddha — Tue, 01 Apr 2025 19:45:38 +0000

If we break it down literally, System Designing means designing a system—simple, right? But the real question is:

"HOW?" 🤔

Let’s dive into it!

What is System Design?

System design is the process of planning and defining the architecture, components, and interactions of a system to meet specific requirements. It involves structuring different elements in a way that ensures efficiency, scalability, and reliability. The goal is to break down complex problems into manageable parts and design each component to work seamlessly as a whole.

System design isn’t a one-time process—it’s an evolving approach that adapts to new challenges and requirements.

How to Approach System Design?

Let’s break it down into a structured roadmap to designing a robust system:

1. Understand the Problem – Identify users, their needs, and system constraints.

2. Define Scope – Set clear boundaries: what the system will and won’t do.

3. Research Existing Systems – Learn from what worked (or failed) in similar systems.

4. High-Level Design – Outline core components and their interactions using diagrams or flowcharts.

5. Refine the Design – Iterate until the solution meets all requirements.

6. Document Everything – Keep records for future reference and scalability.

7. Monitor & Improve – Continuously optimize based on performance and new challenges.

What’s Next?

This is just the beginning! In my next blog, I’ll dive into technical aspects of system design, covering real-world case studies and best practices. Stay tuned! 🚀💡

Mentorship to Full-time Offer | Flipkart SDE-1 Interview Experience

Parul Chaddha — Sun, 01 Sep 2024 22:24:05 +0000

Hello readers!
I’m excited to share my journey of interviewing at Flipkart, which led to an offer for a 6-month internship (January to July) and a full-time Software Development Engineer (SDE-1) role. I got this opportunity through Flipkart’s Girls Wanna Code 5.0 program, a mentorship initiative designed to support Women in Tech.

Out of over 13000+ applications, only 200 women were chosen for the program. From that group, the top 30 were selected for interviews. I feel incredibly lucky to have been one of them, and in this blog, I’ll walk you through my experience and the lessons I learned along the way.

Points considered to be in TOP 30:

1- Your interaction with your mentor : Once you are selected for the program, you will be assigned a mentor
2- Attendance in the sessions : You will get to attend live sessions
3- Scores of the contests held during the mentorship : You will have to clear multiple mini contests
4- Most Important- Scores of the Final Assessment : Usual DSA questions

There were a total of 3 rounds of interview (2 Tech + 1 Hiring Manager ) for all Top 30. Here is my interview experience:

Round 1 : Technical Interview (PS/DS 1) — Offline Flipkart Office,Bengaluru

My first interview was an in-person technical round held at Flipkart’s Bengaluru office. During this hour-long session, I was presented with two DSA (Data Structures and Algorithms) questions — one easy and one medium-level. However, I completed the interview in just 35 minutes.

The first question focused on string manipulation, while the second was a dynamic programming problem named “Unique Paths II” from LeetCode. I was asked to explain my approach, perform a dry run by drawing the recursion tree, and then write the optimized code on the whiteboard.

Round 2 : Technical Interview (PS/DS 2) — Online

My second interview was online and it was an hour long that I concluded in 50 minutes. During this round, I was given one medium-level and one hard-level question.

The first question was to determine if a linked list is a palindrome, and the second involved finding the distance between two nodes in a binary tree.

I explained and wrote both the brute-force and optimized solutions for each problem. The interviewer was satisfied with my approach and solutions.

Round 3: Hiring Manager — Online

This round was a mix of CS fundamentals + Projects + Past Experience + HR questions.

Here is the list of questions that were asked to me.
1- My past internship experience and questions related to that.
2- About Projects and cross-question related to the implementation and its features.
3- What is the difference between process and threads?
4- What is deadlock?(Interviewer wasn’t expecting the bookish language instead a real-life example)
5- Why do we use OOPs ?
6- Difference between SQL and NoSQL databases?
7- What is Cap theorem for NoSQL databases?
8- Some SQL queries.
9- What is Master-Slave architecture in DBMS and it’s working.
10- My ambitions and how am I fit for the role?
11- Why do I want to join Flipkart?
12- Why do we hire you?
13- My strengths and my weaknesses.
14- How will I handle the pressure of work ?
15- What do you think that you need to change in yourself?

RESULTS!!
Finally #Flipkart_it_is!!!! and my happiness knew no bounds after that…….

Resources :

Flipkart Interview Questions on GFG
GFG past interview experiences
DSA sheet by Fraz -> link
DSA sheet by Striver(takeUforward) -> link
DSA sheet by NeetCode -> link

Thank you for reading! In case you need any help, feel free to reach out to me! You can reach out to me for any queries via LinkedIn :) If the blog was helpful, show some love and smash the clap button below!!!

Introduction to Docker

Parul Chaddha — Mon, 16 Oct 2023 12:29:42 +0000

Docker is a set of platforms as a service (PaaS) products that use the Operating system level virtualization to deliver software in packages called containers.

This is something a typical definition but let's understand it in simple terms.

Think of Docker as a delivery service for software. It helps package up software and everything it needs to run into a neat box called a "container."
Each container is like a separate box that holds a specific piece of software. These boxes are very good at keeping things separate and organized.
Inside each container, you'll find the software, the tools it needs to work, and even its own settings. It's like the software's own little world.
These containers can talk to each other if they need to. They have clear rules on how to communicate, like different rooms in a house connected by hallways.
The clever part is that all these containers share the same "house" (the operating system), which makes it efficient. It's like living in an apartment building where everyone shares the same building but has their separate apartments.

Important Terminologies in Docker

1. Docker Image

It is a file, comprised of multiple layers, used to execute code in a Docker container.
They are a set of instructions used to create docker containers. Simple terms explanation: Think of a Docker image as a snapshot of a software application. It's like taking a picture of a cake recipe, all the ingredients, and how to bake it.

2. Docker Container

It is a runtime instance of an image.
Allows developers to package applications with all parts needed such as libraries and other dependencies. Simple terms explanation: A Docker container is like a single, ready-to-eat cake made from the cake recipe image. It's a running instance of a Docker image.

3. Docker file

It is a text document that contains necessary commands which on execution helps assemble a Docker Image.
Docker image is created using a Docker file. Simple terms explanation: Think of a Dockerfile as the list of steps to make the "cake recipe image." It's like writing down all the ingredients and instructions.

4. Docker Engine

The software that hosts the containers is named Docker Engine.
Docker Engine is a client-server based application The docker engine has 3 main components: Server: It is responsible for creating and managing Docker images, containers, networks, and volumes on the Docker. It is referred to as a daemon process. REST API: It specifies how the applications can interact with the Server and instructs it what to do. Client: The Client is a docker command-line interface (CLI), that allows us to interact with Docker using the docker commands. Simple terms explanation: The Docker Engine is like the chef in the kitchen. It's the software that creates and manages containers.

5. Docker Hub

Docker Hub is the official online repository where you can find other Docker Images that are available for use.
It makes it easy to find, manage, and share container images with others. Simple terms explanation: Docker Hub is like an online cookbook where you can find many "cake recipes" (Docker images) created by others. It's a place to share and discover recipes.

Features of Docker:

Open-source platform
An Easy, lightweight, and consistent way of delivery of applications
Fast and efficient development life cycle.
Segregation of duties
Service-oriented architecture
Security
Scalability
Reduction in size
Image management
Networking
Volume management

Architecture of Docker

The Docker client talks with the docker daemon which helps in building, running, and distributing the docker containers. With the help of REST API over a UNIX socket or a network, the docker client and daemon interact with each other.

What is Docker Daemon?
Docker daemon manages all the services by communicating with other daemons. It manages docker objects such as images, containers, networks, and volumes with the help of the API requests of Docker.

Docker Client
With the help of the docker client, the docker users can interact with the docker. The docker command uses the Docker API. The Docker client can communicate with multiple daemons. When a docker client runs any docker command on the docker terminal then the terminal sends instructions to the daemon. The Docker daemon gets those instructions from the docker client withinside the shape of the command and REST API’s request. The common commands which are used by clients are docker build, docker pull, and docker run.

Docker Host
A Docker host is a type of machine that is responsible for running more than one container. It comprises the Docker daemon, Images, Containers, Networks, and Storage.

Docker Registry
All the docker images are stored in the docker registry. There is a public registry which is known as a docker hub that can be used by anyone. We can run our private registry also. With the help of docker run or docker pull commands, we can pull the required images from our configured registry. Images are pushed into configured registry with the help of the docker push command.

Docker Storage
We can store data within the writable layer of the container but it requires a storage driver. Storage driver controls and manages the images and containers on our docker host.

Docker Cloud

Docker Cloud is basically working as a service provider by Docker in which we can perform such as Operation system agnostic, packing only what is needed to run the application in an efficient manner, and easily moving to interact between infrastructure, among many others.

Operations of Docker Cloud

Nodes:– Connection between the cloud services provider such as MS Azure and AWS to run up containers.
Data Processing:– Provide big data processing as a service package.
Cloud Repository:– Provide a platform where we can store a number of versions in a specific Docker Image.
Continuous Implementation:– Connect with GitHub and build a continuous integration pipeline.
App Deployment:– Scale the Infrastructure and Containers with deployment.
Consist Deployment:– it can be automated deployment.

Docker Commands

Docker Run
This command is used to run a container from an image. The docker run command is a combination of the docker create and docker start commands.

$ docker run <image_name>
To give name of container
$ docker run --name <container_name> <image_name>

Docker Pull
This command allows you to pull any image which is present in the official registry of docker, Docker hub. By default, it pulls the latest image, but you can also mention the version of the image.

$ docker pull <image_name>

Docker PS
This command (by default) shows us a list of all the running containers. We can use various flags with it.

-a flag: shows us all the containers, stopped or running.
-l flag: shows us the latest container.
-q flag: shows only the Id of the containers.

$ docker ps [options..]

Docker Stop
This command allows you to stop a container if it has crashed or you want to switch to another one.

$ docker stop <container_ID>

Docker Start
Suppose you want to start the stopped container again, you can do it with the help of this command.

$ docker start <container_ID>

Docker rm
To delete a container.
Some important flags:

-f flag: remove the container forcefully.
-v flag: remove the volumes.
-l flag: remove the specific link mentioned.

$ docker rm {options} <container_name or ID>

Docker Images
Lists all the pulled images which are present in our system.

$ docker images

Docker Login
The Docker login command will help you to authenticate with the Docker hub by which you can push and pull your images.

$ docker login

Docker Push
Once you build your own customized image by using Dockerfile you need to store the image in the remote registry which is DockerHub for that you need to push your image by using the following command.

docker push <Image name/Image ID>

Docker Build
The docker build command is used to build the docker images with the help of Dockerfile.

docker build -t image_name:tag .

In the place of image_name use the name of the image you build with and give the tag number and . “dot” represents the current directory.

Docker Stop
You can stop and start the docker containers where you can do the maintenance for containers. To stop and start specific containers you can use the following commands.

docker stop container_name_or_id

Stop Multiple Containers
Instead of stopping a single container. You can stop multiple containers at a time by using the following commands.

docker stop container1 container2 container3

Docker Restart
While running the containers in Docker you may face some errors and containers fails to start. You can restart the containers to resolve the containers by using the following commands.

docker restart container_name_or_id

Docker Inspection
Docker containers will run into some errors in real time to debug the container’s errors you can use the following commands.

docker inspect container_name_or_id

Docker Commit commands
After running the containers by using the current image you can make the updates to the containers by interacting with the containers from that containers you can create an image by using the following commands.

docker commit container_name_or_id new_image_name:tag

This blog has covered up almost all the basics of Docker.
Hope you liked it .😊😇