HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Untitled Lesson

⚡ Total XP: 0|💻 backend XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Running a database container without a declared volume and losing all data on restart

// Wrong: no volume, data vanishes on 'docker-compose down'
services:
  db:
    image: postgres:15

// Correct: data persists on the host via a named volume
services:
  db:
    image: postgres:15
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

The Solution //

If a docker-compose service for Postgres or MongoDB has no volumes entry, every byte written to disk lives only in the container's writable layer, which is destroyed the instant the container is removed (docker-compose down, a crash, a rebuild). Always attach a named volume to any stateful service's data directory so the data survives independently of the container's lifecycle.

The Error //

Storing user-uploaded files on a container's local volume in a horizontally scaled deployment

// Wrong: file only exists on the instance that received the upload
fs.writeFileSync('/app/uploads/avatar.png', fileBuffer);

// Correct: shared storage every instance can read
await s3.putObject({ Bucket: 'user-uploads', Key: 'avatar.png', Body: fileBuffer }).promise();

The Solution //

A volume attached to one container instance is not shared with other instances, so if a file is uploaded and saved to Container A's volume, a later request routed to Container B will find it missing. Once an app runs as more than one replica, uploaded files must go to shared external storage (like S3) instead of any container-local volume.