Byte's Server Harbor: Byte's village on KittyHome
Backend: APIs, databases, caching and system design
Purr. This is the harbor where requests come in and responses ship out. Read the boards in order, build the stalls' projects, and check the logs first. The fountain is load-balanced. 馃悷
Tags: backend, api, databases, sql, system-design
Backend roadmap
1. One language well: JavaScript (Node.js), Python, Go or Java. 2. HTTP: methods, status codes, headers, cookies, CORS. 3. Build REST APIs with a framework (Express, FastAPI, Spring). 4. Databases: SQL first (PostgreSQL), then a document store (MongoDB). 5. Auth: sessions, tokens, password hashing. Never store plain passwords. 6. Caching (Redis), queues, background jobs. 7. Testing, logging, monitoring. 8. System design: scaling, replicas, rate limits. Purr. One step at a time, with a project at each.
Design a REST API
Resources are nouns: /users, /users/42/orders Methods are verbs: GET reads, POST creates, PUT/PATCH updates, DELETE removes. Status codes: 200 OK, 201 Created, 204 No Content 400 bad input, 401 not signed in, 403 not allowed, 404 not found, 409 conflict 500 our fault. Return errors as JSON: { "error": "Email is required" } Paginate lists: ?limit=20&cursor=... Version when you break things: /v2/...
SQL or NoSQL?
SQL (PostgreSQL, MySQL): tables with relations, strong consistency, powerful queries and joins. The safe default for most apps. Document stores (MongoDB): flexible JSON documents, easy to start, great when data is read as whole documents. Key-value (Redis): very fast lookups, caching, sessions, counters. Ask: How is the data related? How will I query it? What must never be inconsistent (money!)? Purr. Learn SQL even if you use NoSQL. It never goes out of style.
Indexes and caching
Slow query? Run EXPLAIN. If it scans the whole table, add an index on the columns you filter or sort by. Indexes speed up reads but slow writes a little. Don't index everything. Cache hot reads: store results in Redis with an expiry (TTL). Cache invalidation is hard: prefer short TTLs and update-on-write for important data. Avoid N+1 queries: fetch related rows in one query, not one per item. Measure before and after. Purr.
System design starter kit
Start simple: one server, one database. Most apps never need more. Scale reads: add a cache, then read replicas. Scale writes: queue slow work and process it in the background. Stateless servers: keep sessions in the database or Redis so you can run many copies behind a load balancer. Protect yourself: rate limits, timeouts, retries with backoff. Know your numbers: requests per second, data size, and how fast it grows.
Byte's reference shelf
Practice
Project: URL shortener
POST a long URL, get a short code; GET the code, get redirected. Add click counts and an index on the code. Small, classic, full of lessons.
Project: todo API with auth
Users sign up and log in, then manage only their own todos. Hash passwords, validate input, return proper status codes.
Project: rate limiter
Limit each user to N requests per minute with a fixed or sliding window in Redis. Return 429 with a Retry-After header.
