2026 - ITM350 DevOps - Week 06 - Teach One Another: Orchestration.md

Week 6 - Teach One Another: Orchestration

Choose a scenario

Scenario B: An e-commerce app with a Node.js container (backend), a React container (frontend), and a PostgreSQL container (database).

Discuss the following

Identify the key components (services) in your scenario (e.g., frontend, backend, database).

• Frontend: React SPA app
• Backend: NodeJS backend application with ExpressJS
• Database: PostgreSQL
• Optional containers for additional development:
  • Reverse proxy (e.g., Nginx)
  • Caching (e.g., Redis)
  • Background workers (e.g., SendGrid)

Discuss how these components need to interact (e.g., network communication, data persistence).

• React application is deployed to the server and then consumed by clients.
• The frontend communicates with the backend through HTTP requests. Layer 1.
• The backend connects to the PostgreSQL database using internal container networking. Layer 2.
• Validation and security measures are considered when moving data between layers.
• Data is returned from the database back to the backend, processed if necessary and sent to the user/client for display.
• Lastly, the backend should need connection pooling to be able to manage multiple database requests at once.

Theorize what a Docker Compose file might need to include (e.g., service definitions, ports, volumes, dependencies) without writing actual YAML syntax—focus on concepts like “this service depends on that one” or “this needs persistent storage.”

A Docker Compose file would need:

• Service Definitions:
  • frontend service
  • backend service
  • database service
• Dependencies (depends on controls startup order, not readiness):
  • Backend depends on database
  • Frontend depends on backend
• Networking:
  • All services share a default bridge network
  • Backend connects to DB using service name
• Ports:
  • Frontend exposes port 80 or 3000
  • Backend exposes API port (e.g., 5000)
  • Database usually does NOT expose ports externally (only internal network)
• Volumes: PostgreSQL requires a persistent volume for data storage
• Environment Variables:
  • DB_HOST
  • DB_USER
  • DB_PASSWORD
  • DB_NAME
  • API_BASE_URL
  • And others. All variables should be properly placed in production, staging and development storages, so to avoid their use in the wrong places.
• Restart Policy: always (production scenario)
• Resource Limits: CPU and memory limits should be shown to prevent one container from consuming ALL system resources

Assign roles: one student as note-taker (to document in the shared tool), one as timekeeper, and others as contributors.

• We work on this independently and shared personal notes through WhatsApp messaging. We used Google docs and GitHub gists.

Questions

Are there services that rely on others to be up?

• The frontend can run independently but will fail API requests if backend is down.
• The backend can run independently but will fail database operations if DB is unavailable.
• The database can run independently but serves no purpose without the backend.
• Monitoring systems and user contact channels should be set up to alert support and developers when something goes wrong (for example, SMS alerts to developers, triggered from the frontend by final users).

How would you consider scaling the frontend?

Frontend scaling can be achieved by:

• Running multiple frontend replicas. React apps.
• Placing them behind a load balancer.
• Using orchestration platforms like Docker Swarm or Kubernetes.
• Serving static build via CDN for better global performance.
  • I found out that for React specifically, scaling is often simpler because it’s static content.

NOTE: One thing to note though is that in an e-commerce system, scaling the backend is usually a lot more important than scaling the frontend because backend handles real-time requests, database communication, and basically all transactions that are made from the users which is a lot more desired to be faster, and working properly.