Web Backend
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| Backend Software Engineer | Implement server-side business logic, design APIs, model data, optimize performance, write tests, review backend code | Design UI/UX, produce pixel-perfect frontend, manage product marketing or sales logic | GitHub backend, Spotify backend |
| API Engineer | Design clear API contracts, version APIs, write documentation, ensure backward compatibility, measure API performance | Build complex UIs, decide product features, manage frontend state | Stripe API, Google Maps API |
| Full-Stack Developer (backend-leaning) | Implement backend services, connect frontend to APIs, handle auth and persistence, debug across layers | Deep infrastructure ops, large-scale platform design, specialized ML systems | Airbnb web platform, Trello backend |
| Platform / Product Engineer | Build shared backend services, internal tooling, service abstractions, reliability mechanisms | Build customer-facing UI features, work on one-off project logic | Netflix internal services, Uber platform services |
| Cloud / Web Systems Engineer | Deploy backend services, configure CI/CD, monitor systems, handle scaling and failures | Design product features, implement detailed business rules | AWS service backends, Firebase backend |
| Software Engineer (Web Products) | Build and evolve backend systems tied to product needs, iterate quickly, balance speed and quality | Deep research, low-level OS or compiler work | Slack backend, Notion backend |
Affected SDLC Phases
If a team chooses this advanced topic, the system design, implementation, and testing phases are most strongly affected, as the focus shifts toward backend architecture, API design, data modeling, performance, and correctness. Planning and feasibility analysis are still present but are more about scoping technical decisions and trade-offs rather than defining product features. Deployment and maintenance are typically lighter and focus on basic operability, configuration, and evidence of sustainability rather than long-term production support.
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined at least six backend features as API capabilities. Teams must clearly state their chosen backend direction (REST API, GraphQL API, or microservices) and define each feature in terms of planned endpoints or service interfaces, including example requests/responses or schema elements. For every feature, the underlying data storage design (entities/tables/collections and key fields) must be described, and the connection between feature → API/interface → data storage must be clear and traceable.
Technical Details
Before defining features, the team must choose exactly one backend direction: REST API, GraphQL API, or microservice-based backend, and state this clearly in README.md. This choice applies to all features.
Use a consistent feature issue template. Each feature must include: Summary, User value, and Done criteria, plus backend-specific details that match the chosen direction:
REST API: HTTP method and path, brief request/response example, at least one error case
GraphQL API: query or mutation name, relevant schema types/fields, example operation
Microservices: service name responsible, API or message interface to other services
For every feature, also describe the data storage mapping (entities/tables/collections, key fields and relations, and what is created/read/updated/deleted). Keep features small and end-to-end; avoid vague items like “build backend” or “add database”.
Quality
High-quality feature definitions are precise, consistent, and implementable. Each feature clearly defines its API contract (endpoint, operation, or service interface), expected inputs and outputs, and at least one error case. The chosen backend direction is applied consistently across all features, with no mixed styles. Data storage design is understandable and correctly mapped to feature behavior, so it is clear where data lives and how it changes. Feature scopes are small, end-to-end backend capabilities that can be implemented and tested independently, avoiding vague or purely technical tasks.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working backend system based on the chosen backend direction (REST API, GraphQL API, or microservices). The demo must show at least one backend feature working end-to-end, including request handling, data access, and a correct response, with no crashes. The system must be runnable by the tutor using the instructions in README.md, and the demo must show real API interaction (HTTP requests, GraphQL queries, or service-to-service calls), not mockups or code walkthroughs.
Technical Details
The demo must reflect the same backend direction chosen earlier.
REST API: demonstrate a real HTTP request (e.g. curl or Postman) and the corresponding response.
GraphQL API: demonstrate a real query or mutation and its response.
Microservices: demonstrate interaction between services (API call or message) and the resulting behavior.
The demonstrated feature must use the actual data storage layer (database, file, or in-memory store as defined earlier). The demo scenario must be repeatable and documented: how to start the backend, how to invoke the feature, and what output to expect. The video must focus on runtime behavior, not IDEs or source code.
Quality
High-quality work shows a stable, understandable backend demo. The system starts cleanly, handles valid input correctly, and produces predictable output. The demo clearly explains what is happening at the API level and why it matters, without drifting into implementation details. The demonstrated feature aligns with earlier feature definitions and backend design choices. Extra credit comes from clarity, smooth execution, and showing basic robustness (e.g. a handled error case), not from adding more features.
Bug fixing
Minimum Viable Product (MVP)
During development, your team must report and fix one reproducible backend bug related to the chosen backend direction (REST API, GraphQL API, or microservices). The bug must be demonstrated at the API or service level (e.g. failing request, wrong response, or service interaction error). The same steps must reliably reproduce the problem before the fix and must no longer fail after the fix. The bug report and fix must be documented in a single GitLab issue.
Technical Details
The bug issue must clearly describe the runtime scenario: request or operation performed, input data, and observed failure. Include Steps to Reproduce, Expected vs Actual behavior, and evidence (error message, response body, or logs).
The fix must be implemented after the bug is reported, not inline while coding. After fixing, re-run the exact same API call, query, or service interaction and attach proof that the issue is resolved. If applicable, add a small regression check (test or repeatable command) to prevent recurrence.
Quality
High-quality bug fixing shows a clean backend bug lifecycle: clear reproduction, correct diagnosis, and verified resolution. The report focuses on what a user or API consumer observes, not on internal code structure. The fix addresses the root cause, not just the symptom, and does not break existing behavior. Strong submissions briefly explain why the fix works and show that the backend behaves correctly after the change.