Search for a command to run...
Hi there! I'm Aditya, a passionate Full-Stack Developer driven by a love for turning concepts into captivating digital experiences. With a blend of creativity and technical expertise, I specialize in crafting user-friendly websites and applications that leave a lasting impression. Let's connect and bring your digital vision to life!
No comments yet. Be the first to comment.
Explore in-depth articles on AI, full-stack development, system design, software architecture, web technologies, and engineering best practices.
WebSocket is a protocol that enables full-duplex communication between the client and server. Unlike HTTP, which is designed for stateless requests, WebSocket supports long-lived connections. This mak
JavaScript's execution model revolves around scope and execution context. Understanding how variables are accessed, how JavaScript resolves them, and how hoisting works is one of the most frequently t
JavaScript variables and data types form the foundation of the language. Understanding how values are stored, copied, and identified is essential for writing efficient code and answering common interv
I recently watched one of Varun Mayya's talks on distribution, content, and personal branding, and it completely changed the way I think about building a career as a developer. As engineers, we natura
If you've ever been asked questions like: Why is JavaScript called single-threaded? Why does setTimeout(..., 0) run later? What is the Call Stack? What are the Task Queue and Microtask Queue? Wha
Most developers believe that building a great product is enough. It isn't. Thousands of technically excellent products fail every year because nobody knows they exist. The biggest difference between a
Docker Compose is a tool used to define and manage multiple Docker containers using a single YAML file.
Instead of running multiple docker commands manually, Docker Compose allows you to define all services in one configuration file.
Without Compose:
docker run postgres
docker run redis
docker run backend
docker run frontend
With Compose:
docker compose up
Everything starts automatically.
Modern applications rarely consist of a single container.
A typical application may contain:
| Service | Purpose |
|---|---|
| Frontend | React / Next.js |
| Backend | Node.js / Express |
| Database | PostgreSQL |
| Cache | Redis |
| Reverse Proxy | Nginx |
Managing these individually becomes difficult.
Docker Compose solves this problem.
compose.yml
↓
docker compose up
↓
Network Creation
↓
Volume Creation
↓
Container Creation
↓
Application Running
Compose automatically creates:
Containers
Networks
Volumes
Service communication
services:
app:
build: .
db:
image: postgres:16
This starts:
One application container
One PostgreSQL container
Services are the most important concept in Docker Compose.
Each service represents a container.
services:
frontend:
build: ./frontend
backend:
build: ./backend
postgres:
image: postgres:16
Three services create three containers.
Used when Docker should build an image using a Dockerfile.
services:
backend:
build: .
Equivalent command:
docker build .
Custom path:
services:
backend:
build:
context: .
dockerfile: Dockerfile.prod
Used when Docker should pull an image from Docker Hub.
services:
postgres:
image: postgres:16
Examples:
image: redis:7
image: nginx:latest
image: mongo:7
| Feature | Build | Image |
|---|---|---|
| Uses Dockerfile | Yes | No |
| Builds Locally | Yes | No |
| Pulls From Registry | No | Yes |
| Used For Custom Apps | Yes | Yes |
Interview Question:
When should you use build instead of image?
Answer
Use build when creating your own application image. Use image when using pre-built images from Docker Hub.
Provides a custom container name.
services:
backend:
container_name: backend-app
Without this:
project_backend_1
With this:
backend-app
Maps host ports to container ports.
ports:
- "3000:3000"
Format:
HOST:CONTAINER
Example:
ports:
- "8080:3000"
Request:
localhost:8080
Container receives:
3000
Interview Question:
What is the format of port mapping?
Answer
HOST_PORT
Pass runtime variables.
environment:
NODE_ENV: production
PORT: 3000
Example:
services:
backend:
environment:
DATABASE_URL: postgres://user:pass@db:5432/app
Access:
process.env.DATABASE_URL
Store variables in a separate file.
.env
DATABASE_URL=mydb
PORT=3000
Compose:
env_file:
- .env
Benefits:
Cleaner configuration
Easier secret management
Volumes persist data.
volumes:
- postgres-data:/var/lib/postgresql/data
Without volumes:
Container Deleted
↓
Data Deleted
With volumes:
Container Deleted
↓
Data Preserved
Common use cases:
PostgreSQL
MySQL
MongoDB
File uploads
services:
postgres:
image: postgres:16
volumes:
- postgres-data:/var/lib/postgresql/data
volumes:
postgres-data:
Docker manages storage automatically.
Map local folders into containers.
volumes:
- .:/app
Benefits:
Live code updates
Faster development
Common for Next.js and Node.js projects.
Compose automatically creates a network.
Example:
services:
backend:
postgres:
Backend can connect to database using:
postgres
instead of:
localhost
Connection string:
DATABASE_URL=postgresql://user:pass@postgres:5432/db
Interview Question:
How do containers communicate inside Docker Compose?
Answer
Containers communicate through the automatically created Docker network using service names.
Controls startup order.
services:
backend:
depends_on:
- postgres
Docker starts:
Postgres
↓
Backend
Important:
depends_on does not wait until the database is ready.
It only starts containers in order.
Interview Question:
Does depends_on guarantee database readiness?
Answer
No. It only guarantees startup order.
Automatically restart containers.
restart: always
Options:
restart: always
restart: unless-stopped
restart: on-failure
restart: no
Common production setting:
restart: unless-stopped
Override Dockerfile CMD.
Dockerfile:
CMD ["npm", "start"]
Compose:
command: npm run dev
Compose command takes precedence.
Monitors container health.
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000"]
interval: 30s
timeout: 10s
retries: 3
Benefits:
Better monitoring
Automatic recovery
Production readiness
Run only selected services.
services:
postgres:
profiles:
- development
Run:
docker compose --profile development up
Useful for:
Development
Testing
Production
Node.js + PostgreSQL
services:
backend:
build: .
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://admin:secret@postgres:5432/app
depends_on:
- postgres
postgres:
image: postgres:16
environment:
POSTGRES_USER: admin
POSTGRES_PASSWORD: secret
POSTGRES_DB: app
volumes:
- postgres-data:/var/lib/postgresql/data
volumes:
postgres-data:
Start:
docker compose up
Everything starts automatically.
Start:
docker compose up
Background mode:
docker compose up -d
Stop:
docker compose down
View logs:
docker compose logs
Follow logs:
docker compose logs -f
List containers:
docker compose ps
Restart:
docker compose restart
Build:
docker compose build
Rebuild:
docker compose up --build
A tool used to define and manage multi-container Docker applications using a YAML file.
| Dockerfile | Docker Compose |
|---|---|
| Builds Images | Runs Containers |
| Defines Environment | Defines Services |
| Creates Images | Creates Application Stack |
Through Docker networks using service names.
Defines container startup order.
No.
Persistent data storage.
| Bind Mount | Named Volume |
|---|---|
| Uses Host Directory | Managed By Docker |
| Good For Development | Good For Production |
Containers and networks are removed.
Volumes remain unless explicitly deleted.
Yes.
Using:
build: .
image: postgres:16
Avoid:
image: postgres:latest
Use healthchecks.
Use named volumes for databases.
Store secrets in environment files.
Separate development and production configurations.
Use restart policies.
Avoid hardcoded credentials.
Keep services isolated.
| Mistake | Problem |
|---|---|
| Using latest tag | Unexpected updates |
| No volumes | Data loss |
| No healthchecks | Difficult monitoring |
| Hardcoded secrets | Security risk |
| Using localhost for DB | Container communication failure |
| Keyword | Purpose |
|---|---|
| services | Define containers |
| build | Build image |
| image | Pull image |
| container_name | Custom name |
| ports | Port mapping |
| environment | Runtime variables |
| env_file | External variables |
| volumes | Persistent storage |
| networks | Service communication |
| depends_on | Startup order |
| restart | Auto restart |
| command | Override CMD |
| healthcheck | Health monitoring |
| profiles | Environment-specific services |
In real interviews, Docker Compose questions are usually scenario-based.
Interviewers want to evaluate:
Service communication
Networking knowledge
Volume management
Environment variables
Startup dependencies
Production readiness
This guide contains common interview scenarios and their solutions.
You have a Node.js backend and PostgreSQL database.
Requirements:
Backend should run on port 3000
PostgreSQL should run on port 5432
Backend should connect to PostgreSQL
Database data should persist after container restart
Write a Docker Compose file.
services:
backend:
build: .
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://admin:secret@postgres:5432/app
depends_on:
- postgres
postgres:
image: postgres:16
environment:
POSTGRES_USER: admin
POSTGRES_PASSWORD: secret
POSTGRES_DB: app
volumes:
- postgres-data:/var/lib/postgresql/data
volumes:
postgres-data:
Backend connects using:
postgres
NOT
localhost
Because containers communicate through service names.
Correct:
DATABASE_URL=postgresql://admin:secret@postgres:5432/app
Wrong:
DATABASE_URL=postgresql://admin:secret@localhost:5432/app
To prevent database data loss.
To ensure PostgreSQL starts before Backend.
No.
Create a Compose file where:
Backend runs on port 3000
Redis runs on port 6379
Backend uses Redis for caching
services:
backend:
build: .
ports:
- "3000:3000"
environment:
REDIS_URL: redis://redis:6379
depends_on:
- redis
redis:
image: redis:7
Backend can access Redis using:
redis
because Redis service name becomes DNS hostname.
How does Backend discover Redis?
Answer:
Docker Compose automatically creates a network and service names become hostnames.
You have:
React Frontend
Express Backend
Both should communicate through Docker network.
Frontend runs on:
localhost:5173
Backend runs on:
localhost:3000
services:
frontend:
build: ./frontend
ports:
- "5173:5173"
backend:
build: ./backend
ports:
- "3000:3000"
Frontend should call:
http://backend:3000
inside Docker network.
Not:
http://localhost:3000
Many candidates use:
localhost
This is wrong because each container has its own localhost.
Create a Compose file containing:
Next.js
Express
PostgreSQL
Redis
All services should communicate.
services:
frontend:
build: ./frontend
ports:
- "3000:3000"
backend:
build: ./backend
ports:
- "4000:4000"
environment:
DATABASE_URL: postgresql://admin:secret@postgres:5432/app
REDIS_URL: redis://redis:6379
depends_on:
- postgres
- redis
postgres:
image: postgres:16
environment:
POSTGRES_USER: admin
POSTGRES_PASSWORD: secret
POSTGRES_DB: app
volumes:
- postgres-data:/var/lib/postgresql/data
redis:
image: redis:7
volumes:
postgres-data:
Frontend
↓
Backend
↓ ↓
Redis PostgreSQL
How many networks are created?
Answer:
One default network.
How does Backend connect to PostgreSQL?
Answer:
Using hostname:
postgres
How does Backend connect to Redis?
Answer:
Using hostname:
redis
Create two services that communicate using a custom Docker network.
services:
backend:
build: .
networks:
- app-network
postgres:
image: postgres:16
networks:
- app-network
networks:
app-network:
backend
↓
app-network
↑
postgres
Both services belong to the same network.
Therefore:
backend
can communicate with:
postgres
You have:
Frontend
Backend
Database
Database should NOT be accessible by Frontend.
Design the network architecture.
services:
frontend:
build: ./frontend
networks:
- public
backend:
build: ./backend
networks:
- public
- private
postgres:
image: postgres:16
networks:
- private
networks:
public:
private:
Frontend
|
Public
|
Backend
|
Private
|
Postgres
Frontend cannot directly access PostgreSQL.
Only Backend can.
This is a common production setup.
Your PostgreSQL data disappears after container recreation.
How would you fix it?
services:
postgres:
image: postgres:16
volumes:
- postgres-data:/var/lib/postgresql/data
volumes:
postgres-data:
What happens if the container is deleted?
Answer:
Data remains inside the volume.
Move all sensitive values out of compose.yml.
.env
POSTGRES_USER=admin
POSTGRES_PASSWORD=secret
POSTGRES_DB=app
compose.yml
services:
postgres:
image: postgres:16
env_file:
- .env
Better security.
Cleaner configuration.
Ensure Backend starts only when PostgreSQL becomes healthy.
services:
postgres:
image: postgres:16
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
Health checks allow Docker to monitor service readiness.
What would you add before deploying to production?
Named volumes
Health checks
Restart policies
Environment files
Fixed image versions
Separate networks
Resource limits
Logging configuration
Example:
restart: unless-stopped
healthcheck:
volumes:
env_file:
Using localhost between containers.
Wrong:
localhost
Correct:
service-name
No volume for database.
Result:
Container Deleted
↓
Data Lost
Using latest image tag.
Wrong:
image: postgres:latest
Correct:
image: postgres:16
Thinking depends_on waits for readiness.
It does not.
It only controls startup order.
Exposing database publicly.
Wrong:
ports:
- "5432:5432"
Not always necessary.
Expose only when needed.
| Question | Expected Answer |
|---|---|
| How do containers communicate? | Service Name |
| What creates networking? | Docker Compose |
| How to persist data? | Volumes |
| Build vs Image? | Custom vs Existing Image |
| What is depends_on? | Startup Order |
| Does depends_on wait? | No |
| How to store secrets? | env_file |
| Why healthchecks? | Readiness Monitoring |
| Why custom networks? | Isolation |
| Why named volumes? | Data Persistence |
Docker Compose is used to manage multiple containers as a single application. It simplifies networking, storage, environment configuration, startup order, and deployment. Understanding services, build, image, ports, environment variables, volumes, networks, and depends_on is sufficient for handling most real-world projects and Docker-related interviews.