ข้ามไปยังเนื้อหา

เนื้อหาหลักของหน้านี้เป็นภาษาอังกฤษแปลหน้านี้

โรดแมปสายอาชีพ

Backend Developer roadmap

Backend developers build the servers, APIs and data systems that power apps. You will learn a backend language, databases, APIs, authentication, caching, queues and deployment, and how to design systems that scale.

เวลา
⏱ 5–6 months
Level
Intermediate
Steps
6 steps
Architecture ↓Cheat sheet ↓5 interview Q&As ↓
แชร์

The roadmap

Click a step to open the full guide.

Best architecture: a scalable backend service

The standard backend setup that scales from one server to many.

Backend reference

  1. Load balancer / API gateway
  2. Stateless API servers (autoscaled)
  3. Cache (Redis) · Queue → workers
  4. Primary DB + read replicas
  5. Logs · metrics · traces

Why it's built this way

  • Stateless servers scale horizontally behind the load balancer.
  • Cache-aside สำหรับปี hot reads; queues สำหรับปี slow work.
  • Replicas สำหรับปี reads; shard only when needed.
  • Observability from day one.

Backend Developer cheat sheet

The essentials on one screen. Bookmark it for revision.

HTTP status codes

200 / 201 / 204OK / Created / No content
400Bad request (validation failed)
401 / 403Not logged in / not allowed
404 / 409Not found / conflict
429Too many requests (rate limited)
500 / 503Server error / unavailable

Building blocks

Load balancerSpread traffic across servers
CacheFast reads for hot data
QueueAsync work, smooth spikes
ReplicaScale reads, failover
ShardSplit data for huge scale
CDNStatic content near users

Improve performance

  • Fix the database first: indexes, no N+1 queries, connection pooling.
  • Cache hot reads with clear TTLs and invalidation.
  • Paginate and return only needed fields.
  • Move slow work to queues and background workers.
  • Scale horizontally with stateless services behind a load balancer.
  • Measure p95/p99 latency, not just averages.

Security checklist

  • Validate all input; parameterised queries against injection.
  • Check authorisation on every request (object-level access).
  • Hash passwords (bcrypt/Argon2); use MFA for admin.
  • HTTPS everywhere; secure headers; rate limiting.
  • Secrets in a secrets manager; least-privilege service accounts.
  • Log security events and keep dependencies patched.

Most important interview questions

Click a question to see a strong answer. Each step also has its own questions.

1What happens when a request hits your backend?

DNS → load balancer → web server/app → middleware (auth, logging) → validation → business logic → database/cache → response serialised and returned.

2How do you scale a backend to millions of users?

Stateless app servers behind load balancers, caching, CDNs, read replicas, sharding when needed, queues for async work, and monitoring to find bottlenecks.

3Explain the CAP theorem.

During a network partition, a distributed data store can guarantee either consistency or availability, not both.

4How do you prevent SQL injection?

Always use parameterised queries or a safe ORM, validate input, and give the database user minimal privileges.

5Monolith or microservices?

Start with a well-structured monolith; split into services only when team size, scaling or deployment needs clearly justify the added complexity.

Related โรดแมป

6

Python Developer

6 steps · 4–5 months · Beginner

Build backends, automation and data tools with Python.

View roadmap →
6

FastAPI

6 steps · 3–4 weeks · Intermediate

Build fast, documented Python APIs.

View roadmap →
6

PostgreSQL & SQL

6 steps · 4–5 weeks · Beginner

The database most new apps choose.

View roadmap →
6

Full Stack Developer

6 steps · 6–8 months · Intermediate

Build complete web apps, front to back.

View roadmap →
1

Backend Developer · Step 1 of 6 · 4 weeks

A backend language

Pick one and go deep.

The language matters less than depth. Python is great for AI-heavy backends, Node.js for JavaScript teams, Java for large enterprises and Go for high-performance services.

Check which languages local job listings ask for most and choose accordingly.

What you'll learn

  • Python, Node.js, Java or Go
  • Data structures
  • Error handling
  • Concurrency basics
  • Testing
  • Package management

Popular backend languages

Python

  • AI & data friendly
  • FastAPI, Django

Node.js / TS

  • Same language as frontend
  • Express, NestJS

Java / Go

  • Enterprise & high performance
  • Spring, Go std lib

Key concepts

Concurrency vs parallelism
Concurrency: juggling many tasks. Parallelism: doing many at the same instant on multiple cores.
Blocking I/O
Waiting idle for network/disk instead of doing other work.

Step by step

  1. 1.1

    Choose a language

    Python, Node.js, Java or Go based on local jobs.

  2. 1.2

    Core skills

    Data structures, error handling, modules, testing.

  3. 1.3

    Concurrency

    Async I/O vs threads vs processes.

Notes

  • Concurrency (async, threads) is a common interview topic.

Tips & tricks

  • Write unit tests from the start.

Interview questions

Concurrency vs parallelism?

Concurrency is structuring a program to handle many tasks that overlap in time (e.g. async I/O). Parallelism is executing multiple tasks at the same moment on multiple CPU cores.

The quick way to study this

Pick the language most requested in your city's job posts and code daily.

Python roadmap →
2

Backend Developer · Step 2 of 6 · 3 weeks

Databases and SQL

Model and query data correctly.

Most backend performance problems are database problems. Learn to design tables, add the right indexes and read query plans.

Use NoSQL when it fits (caching, flexible documents), not by default.

What you'll learn

  • Relational design and normalisation
  • PostgreSQL
  • Indexes and query plans
  • Transactions and isolation
  • NoSQL basics (Redis, MongoDB)
  • Migrations

SQL vs NoSQL

SQL (PostgreSQL)

  • Tables & relations
  • Strong consistency
  • Joins & transactions

NoSQL (Redis, Mongo, Dynamo)

  • Flexible or key-value
  • Easy horizontal scale
  • Fewer joins

Key concepts

Index
Speeds reads, slows writes slightly.
ACID
Guarantees that make transactions safe.
CAP theorem
In a network split, a distributed system must choose consistency or availability.

Step by step

  1. 2.1

    Model data

    Entities, relationships, keys and constraints.

  2. 2.2

    Query and index

    Write queries; index for real access patterns.

  3. 2.3

    Transactions

    Keep multi-step changes consistent.

  4. 2.4

    Know NoSQL

    Redis for cache/queues; documents when schema varies.

Notes

  • Add indexes for columns you filter and join on.

Tips & tricks

  • Run EXPLAIN ANALYZE before and after adding an index.

Interview questions

How do you design a database schema for an e-commerce app?

Tables for users, products, orders and order_items (many-to-many between orders and products), with foreign keys, constraints, indexes on lookup columns, and prices copied into order_items at purchase time.

The quick way to study this

Design the schema for an e-commerce app and write its 10 most common queries.

PostgreSQL roadmap →
3

Backend Developer · Step 3 of 6 · 3 weeks

API design

REST, validation and documentation.

Good APIs are predictable: consistent names, clear errors, pagination and versioning. Document them with OpenAPI so others can use them easily.

FastAPI (Python) and Express or NestJS (Node.js) are popular choices.

What you'll learn

  • REST conventions
  • Status codes and errors
  • Pagination and filtering
  • Validation
  • OpenAPI docs
  • GraphQL and gRPC basics

Request lifecycle

  1. Client
  2. Load balancer
  3. Auth middleware
  4. Validation
  5. Business logic
  6. Database
  7. Response

Key concepts

Idempotent
Repeating the request has the same result (GET, PUT, DELETE).
Cursor pagination
Continue from the last item seen; stable and fast for big tables.

Step by step

  1. 3.1

    Resource naming

    Plural nouns: /orders/{id}/items.

  2. 3.2

    Errors

    Consistent error format with codes and messages.

  3. 3.3

    Pagination and filters

    Cursor-based for large data.

  4. 3.4

    Versioning and docs

    /v1/, OpenAPI documentation.

Notes

  • Return helpful error messages, never stack traces, to clients.

Tips & tricks

  • Design the API on paper before coding.

Interview questions

REST vs GraphQL vs gRPC?

REST: simple, cacheable resource URLs. GraphQL: clients ask for exactly the fields they need. gRPC: fast binary calls between services with strict contracts.

How do you make a POST endpoint safe to retry?

Accept an idempotency key from the client and store the result, so repeated requests with the same key return the original result.

The quick way to study this

Build a documented REST API with pagination and validation.

FastAPI roadmap →
4

Backend Developer · Step 4 of 6 · 3 weeks

Auth, security and caching

Protect users and speed things up.

Never store plain passwords; use a slow hashing algorithm such as bcrypt or Argon2. Understand the common web risks: injection, broken access control, exposed secrets.

Caching with Redis can make slow endpoints instant; plan how to invalidate cached data.

What you'll learn

  • Password hashing
  • Sessions vs JWT
  • OAuth basics
  • OWASP top risks
  • Redis caching
  • Rate limiting

Cache-aside pattern

  1. Request
  2. Check cache
  3. Hit → return
  4. Miss → query DB
  5. Store in cache
  6. Return

Key concepts

Authentication vs authorisation
AuthN = who you are; AuthZ = what you may do.
Cache invalidation
Removing or refreshing cached data when the source changes.
TTL
Time to live: how long a cached item is kept.

Step by step

  1. 4.1

    Authentication

    Who are you? Sessions or tokens; OAuth for third parties.

  2. 4.2

    Authorisation

    What may you do? Check on every request.

  3. 4.3

    OWASP Top 10

    Injection, broken access control, misconfiguration…

  4. 4.4

    Caching

    Redis with clear invalidation rules and TTLs.

Notes

  • Check permissions on every request, not just at login.

Tips & tricks

  • Use well-known auth libraries; do not invent your own.

Interview questions

Sessions vs JWTs?

Sessions store state on the server and are easy to revoke. JWTs are self-contained and scale without lookups but are harder to revoke, so keep them short-lived with refresh tokens.

The quick way to study this

Add login, roles and a Redis cache to your API.

5

Backend Developer · Step 5 of 6 · 3 weeks

Queues, deployment and observability

Run services reliably.

Slow work (emails, reports, AI calls) belongs in background jobs. Containers and CI/CD make deployments repeatable.

Good logs and metrics let you fix problems before users complain.

What you'll learn

  • Background jobs and queues
  • Docker
  • CI/CD
  • Cloud deployment
  • Logging, metrics and tracing
  • Health checks

Async job processing

  1. API receives request
  2. Put job on queue
  3. Return 202 + job id
  4. Worker processes
  5. Store result / notify

Key concepts

Message queue
A buffer between producers and workers that smooths spikes.
Three pillars of observability
Logs, metrics, traces.

Step by step

  1. 5.1

    Queues

    Send slow work (emails, reports, AI calls) to workers.

  2. 5.2

    Containers and CI/CD

    Build, test and deploy automatically.

  3. 5.3

    Observability

    Structured logs, metrics, traces and alerts.

Notes

  • Make background jobs safe to retry (idempotent).

Tips & tricks

  • Add structured JSON logs with a request ID.

Interview questions

the difference between monitoring and observability คืออะไร

Monitoring watches known metrics and alerts. Observability lets you ask new questions about system behaviour using logs, metrics and traces.

The quick way to study this

Deploy your API with Docker, a worker and basic monitoring.

Docker & Kubernetes roadmap →AWS roadmap →
6

Backend Developer · Step 6 of 6 · 2 weeks

System design basics

Design systems that scale.

System design interviews test how you think about scale, reliability and trade-offs. Learn common building blocks and when to use each.

Always start with requirements and rough numbers (users, requests per second, data size).

What you'll learn

  • Load balancing
  • Horizontal scaling
  • Database replication and sharding
  • CDNs
  • Message brokers
  • Trade-offs and estimates

A scalable web system

  1. Clients + CDN
  2. Load balancer
  3. Stateless app servers (autoscaled)
  4. Cache (Redis) + queue
  5. Primary DB + read replicas
  6. Object storage

Key concepts

Horizontal scaling
Add more machines; needs stateless services.
Replication vs sharding
Replication copies data for reads/availability; sharding splits data across machines.
CDN
Servers worldwide that cache content near users.

Step by step

  1. 6.1

    Requirements

    Users, requests per second, data size, latency goals.

  2. 6.2

    High-level design

    Clients, load balancer, services, databases, caches, queues.

  3. 6.3

    Deep dives

    Bottlenecks, scaling, failure handling, trade-offs.

Notes

  • There is no perfect design, only trade-offs you can explain.

Tips & tricks

  • Practise designing a URL shortener, a chat app and a news feed.

Interview questions

Design a URL shortener.

API to create and resolve codes; generate short unique IDs (base62 of a counter or random with collision check); store mapping in a key-value DB; cache popular codes; redirect with 301/302; add analytics asynchronously; scale reads with cache and replicas.

The quick way to study this

Study five classic designs and explain each in 15 minutes.

แชร์หน้านี้