Interview theory · backend engineering

Backend Engineer Theory

114 topics · 18 sections · plain explanations with concrete examples, tagged by level

OS & Concurrency

fundamentals

Networking & APIs

fundamentals

Database

data

PostgreSQL & Redis Deep Dive

data

Design Patterns & Principles

design

Domain-Driven Design

design

Testing & Quality

quality

Security Fundamentals

quality

DevOps & Containerization

infra

Monitoring, Alerting & Logging

infra

Distributed Systems & Messaging

distributed

Resilience & Kafka Operations

distributed

System Design Fundamentals

system design

System Design Case Studies

system design

Troubleshooting Scenarios

operations

DSA Pattern Cheat Sheet

coding

Go (GoLang)

language

Behavioral & Senior Signals

career

OS & Concurrencyjunior

Process vs Thread

A process is an independent running program with its own memory space. It is isolated, so a crash in one process doesn't directly corrupt another. A thread is a unit of execution within a process, sharing that process's memory with other threads in it. Threads are cheaper to create and switch than processes, but shared memory means threads can step on each other's data without synchronization.

Example

Process (own memory space, PID)
 ├── Thread 1 (main)
 ├── Thread 2
 └── Thread 3   ← all share the process's memory

A web server process handles many requests using a pool of threads: all threads share the same loaded application code/memory (fast to spin up), but a shared in-memory counter accessed by two threads at once needs a lock or it'll be corrupted.

Python:
  multiprocessing.Process(target=crunch).start() # process: own memory, true parallelism
  threading.Thread(target=fetch).start()         # thread: shared memory, GIL caps CPU work

Go:
  exec.Command("worker").Start()    // separate OS process, isolated memory
  go handle(req)                    // goroutine: runtime-managed, shared memory

Real world: Chrome runs every tab as its own process, so one crashed tab never kills the browser. Gunicorn: -w 4 --threads 2 = 4 processes × 2 threads = 8 concurrent requests. PostgreSQL spawns one process per connection: that is exactly why max_connections stays small and PgBouncer exists.