Backend Development

What a backend is, how clients and servers find each other, and the parts of every web conversation: URLs, HTTP methods, status codes, headers and JSON.

1. What is a backend?The backend is the part of an app that runs on a server, not on your phone. It stores data, checks rules and sends answers back to the app. When you book a train ticket, the screen you tap is the frontend; the computer that checks seats and saves your booking is the backend.20 min
2. Clients, servers, IP addresses and URLsA client is the program that asks, like your browser or a phone app. A server is the computer that answers. Every server has a number called an IP address, and DNS turns easy names like irctc.co.in into that number. A URL tells the client which server, which port and which page to ask for.25 min
3. HTTP requests, responses and methodsHTTP is the set of rules browsers and servers use to talk. Every request has a method (like GET or POST), a path, headers and sometimes a body. The method says what you want to do: read, create, replace, change or delete. Some methods are safe (they only read) and some are idempotent (doing them twice is the same as doing them once).25 min
4. HTTP status codesEvery response starts with a status code, a three-digit number that tells the client what happened. Codes in the 200s mean success, 300s mean "look somewhere else", 400s mean the client made a mistake and 500s mean the server failed. Picking the right code helps apps, browsers and developers react correctly.20 min
5. HTTP headers and cookiesHeaders are extra details sent with every request and response, written as name: value pairs. They say what kind of data the body holds, who is logged in, how long to cache a page and much more. Header names do not care about capital letters, so Content-Type and content-type are the same header.20 min
6. JSON: the language of APIsJSON (JavaScript Object Notation) is a simple text format for data. Almost every API sends and receives JSON. In JavaScript, JSON.stringify turns an object into JSON text and JSON.parse turns JSON text back into an object. Bad JSON makes JSON.parse throw an error, so always parse outside data inside try and catch.25 min

Design clean REST APIs, route each request to the right handler, build a full CRUD API, validate every input and answer errors in one safe, consistent shape.

1. What an API is and how REST APIs are designedAn API is a set of rules that lets one program ask another program for data or actions. A REST API treats data as resources with plural noun URLs like /users and /users/42, and uses the HTTP method to say what to do. Clear, predictable URLs make an API easy to learn and hard to misuse.25 min
2. Routing: sending each request to the right codeRouting means looking at the method and path of a request and choosing the function that should handle it. A route table lists patterns like GET /users/:id, where :id is a path parameter that can be any value. Query strings carry extra options and are read with URLSearchParams.25 min
3. Handling requests: a full CRUD APIA handler reads a request and returns a response. With a list of records kept in memory, you can build the four basic actions of almost every app: create, read, update and delete, called CRUD. Each action has its own method, status code and a 404 when the record does not exist.30 min
4. Validating inputValidation means checking every piece of data that reaches your server before you use it. Anyone can send any request, so never trust input: check that required fields exist, have the right type and length, and follow the right format, like a 10-digit Indian mobile number. Return all the problems at once with a 400 or 422 status.25 min
5. Handling errors wellThings go wrong: bad input, missing records, a crashed database. Good backends answer every error with the right status code and the same JSON shape, like { error: { code, message } }. Unexpected crashes are caught, logged in full on the server, and answered with a plain 500 that never shows the real error to the user.25 min

Run JavaScript on a server with Node.js, understand async code and the event loop, build an API with Express, add middleware and keep settings and secrets in environment variables.

1. Node.js: JavaScript on the serverNode.js lets you run JavaScript on a computer or server, not only inside a web browser. It is fast at jobs that wait a lot, like reading a database or calling another service, because it does not sit idle while it waits. You install it once, run files with the node command, and add ready-made code with npm.25 min
2. Express: your first web serverExpress is a small framework for building web servers with Node.js. You tell it which function should answer which URL and method, and it does the rest: reading requests, sending JSON and handling errors. With about ten lines you have a working API.25 min
3. Middleware: checks before your handlerMiddleware is a function that runs between the request arriving and your route handler. Each one can look at the request, change it, stop it with a response, or pass it on by calling next(). Loggers, JSON reading, login checks and error handlers are all middleware.25 min
4. Environment variables and configEnvironment variables are settings given to your program from outside the code, like the port number or the database address. Node.js reads them from process.env. Secrets go in a .env file that you never commit to Git, and your app should check its settings as soon as it starts.20 min

Learn why apps use databases, how tables, rows and keys work, and write real SQL: SELECT with WHERE, sorting and pages, INSERT, UPDATE and DELETE, and counts and totals with aggregate functions.

1. What is a database?A database is a program that stores your app's data safely and finds any part of it fast. Most databases keep data in tables of rows and columns, like a very strict spreadsheet. You talk to them in SQL, a short language of commands like SELECT and CREATE TABLE.20 min
2. SELECT and WHERE: finding rowsSELECT picks which columns you want and WHERE picks which rows. With =, >, <, AND, OR, IN, BETWEEN, LIKE and IS NULL you can ask almost any question of a table, like "students from Pune with marks above 70".25 min
3. ORDER BY, LIMIT and DISTINCTORDER BY sorts the rows a query returns, LIMIT keeps only the first few, and OFFSET skips some, which is how apps show page 1, page 2 and so on. DISTINCT removes repeated rows and AS gives a column a nicer name.20 min
4. INSERT, UPDATE and DELETEINSERT adds new rows, UPDATE changes rows that already exist, and DELETE removes rows. UPDATE and DELETE need a WHERE clause to choose the rows, or they change every row in the table.25 min
5. Counting and totals: aggregate functionsAggregate functions turn many rows into one answer: COUNT counts rows, SUM adds, AVG finds the average, and MIN and MAX find the smallest and largest. With GROUP BY you get one answer per group, like total sales per city.25 min

Go beyond single-table queries: join tables, group and filter totals, write subqueries and CTEs, speed queries up with indexes, keep money safe with transactions, and design tables that do not repeat data.

1. Joins: combining tablesReal databases keep customers, orders and products in separate tables and link them with ids. A JOIN puts matching rows from two tables side by side in one result. INNER JOIN keeps only rows that match on both sides; LEFT JOIN keeps every row from the left table, even with no match, so you can find customers who never ordered.20 min
2. GROUP BY and HAVINGGROUP BY splits rows into groups that share a value, like one group per city, and an aggregate such as SUM or COUNT then gives one answer per group. WHERE filters rows before grouping; HAVING filters the groups after. Every column you select must either be in GROUP BY or be inside an aggregate.20 min
3. Subqueries, CTEs and window functionsA subquery is a query inside another query, for example "products priced above the average price". You can use one in WHERE, with IN or EXISTS, or in FROM as a temporary table. A CTE (WITH name AS ...) gives that temporary table a name so long queries read top to bottom. Window functions like ROW_NUMBER rank rows inside groups without collapsing them.20 min
4. Indexes: making queries fastAn index is a sorted copy of one or more columns with pointers back to the rows, so the database can jump to matching rows instead of reading the whole table. Indexes make reads fast but make every insert and update a little slower. Index the columns you search, join and sort on, and check with EXPLAIN that the index is really used.18 min
5. Transactions and ACIDA transaction groups several SQL statements so they all happen or none of them happen. A UPI transfer debits one account and credits another; if the server crashes in between, the money must not vanish. You start with BEGIN, save with COMMIT, or undo everything with ROLLBACK.20 min
6. Normalisation and table designNormalisation means designing tables so each fact is stored only once. When the same fact sits in many rows, updates miss some copies and the data starts to disagree. The normal forms (1NF, 2NF, 3NF) are simple checks for this, and many-to-many links get their own junction table.20 min

Go beyond plain SQL: store documents in MongoDB, talk to databases through an ORM without falling into the N+1 trap, send big lists page by page, and accept file uploads safely with object storage.

1. NoSQL and MongoDBNoSQL databases do not keep data in tables of rows and columns. MongoDB, the most popular one, stores JSON-like documents inside collections. It is handy when each record has a different shape, but for money, stock and data with many links, a SQL database is usually the safer choice.30 min
2. ORMs: working with databases from codeAn ORM (Object-Relational Mapper) lets you read and write database rows as normal objects in your programming language. It writes the SQL for you, keeps your schema in migrations and saves a lot of typing. You still need to understand SQL, because careless ORM code can fire hundreds of queries where one would do.30 min
3. Pagination: sending data page by pagePagination means sending a long list in small pages instead of all at once. The simple way uses LIMIT and OFFSET with a page number. For very big or fast-changing tables, cursor (keyset) pagination is faster: it asks for "the next 20 after this id".25 min
4. Handling file uploads safelyUsers upload photos, PDFs and documents through multipart/form-data requests. A safe backend limits the size, checks the real file type from its first bytes, never trusts the file name, and stores the file in object storage such as S3 or Cloudflare R2. The database keeps only the file key and details.30 min

Log users in safely and decide what each one may do: store passwords with slow salted hashes, keep people logged in with sessions or JWTs, add Google login, OTP and passkeys, and check permissions on the server for every request.

1. Storing passwords safelyNever store a password as it was typed. Store a hash: a one-way fingerprint made by a slow password-hashing function such as Argon2id or bcrypt, with a random salt for every user. At login you hash the typed password again and compare the results.30 min
2. Sessions and cookiesHTTP forgets you after every request, so after login the server creates a session and gives the browser a random session id in a cookie. The browser sends the cookie back with each request, and the server looks up who you are. Safe cookies use HttpOnly, Secure and SameSite, and logout destroys the session on the server.30 min
3. JSON Web Tokens (JWT)A JWT is a signed token that carries facts about a user, such as their id and when the token expires. The server can check the signature without looking anything up in a database. Anyone can read a JWT, so never put secrets in it, and always verify the signature before trusting it.30 min
4. Login with Google, OTP and passkeys"Login with Google" uses OAuth 2.0 and OpenID Connect: Google checks the user and sends your backend a signed proof of who they are. OTP login sends a short one-time code by SMS or email, which is very common in India. Passkeys are the modern passwordless option, using a key stored safely on the user's phone.30 min
5. Authorization: who can do whatAuthorization decides what a logged-in user is allowed to do. Give each user a role with a list of permissions, check ownership so people can only touch their own data, and do these checks on the server for every request. Missing checks, called broken access control, are the most common serious web bug.30 min

Learn the most common ways web apps get attacked and how a backend developer stops them: the OWASP Top 10, SQL injection, XSS and CSRF, and keeping secrets like API keys safe.

1. The OWASP Top 10: the most common web risksOWASP is a free, open community that helps people build safer software. Its best-known project is the Top 10: a short list of the most common and serious risks in web apps, such as broken access control and injection. Backend developers use it as a checklist when they build and review an app.25 min
2. SQL injection and how to stop itSQL injection happens when text typed by a user is glued into an SQL query, so the user can change what the query does. One clever input can show every row, delete a table or skip a login. The fix is simple: send values separately from the query with placeholders (parameterised queries), and give the app a database user with only the rights it needs.25 min
3. XSS and CSRF: attacks through the browserXSS (cross-site scripting) is when an attacker gets their own JavaScript to run on your website, inside other users' browsers. CSRF (cross-site request forgery) is when another website tricks a logged-in user's browser into sending a request to your site. You stop XSS by escaping output and using a Content-Security-Policy, and CSRF with SameSite cookies, CSRF tokens and Origin checks.30 min
4. Keeping secrets safeSecrets are values that give power: API keys, database passwords, JWT signing keys. They must never be written in code or pushed to git. Keep them in environment variables or a secret manager, change them from time to time, never print them in logs, and if one leaks, revoke it first and ask questions later.25 min

Make a backend fast and dependable under real traffic: cache with Redis, move slow work to background jobs, protect APIs with rate limits, and see what is happening with logs, metrics and alerts.

1. Caching and RedisA cache keeps a copy of data that is slow to get, so the next request can be answered fast. The common pattern is cache-aside: look in the cache, and only on a miss ask the database and save the answer with a time limit (TTL). Redis is a very fast in-memory store used for this. The hard part is making sure old (stale) data does not stay too long.30 min
2. Background jobs and queuesSlow work like sending emails, making PDFs or resizing photos should not happen while the user waits for a response. Instead, the app puts a job in a queue and answers at once; a separate worker program picks up jobs and does them. Good job systems retry failures with growing waits, make repeated jobs safe with idempotency keys, and park jobs that keep failing in a dead-letter queue.30 min
3. Rate limitingRate limiting means allowing only a certain number of requests in a period, like 5 OTP requests per phone number per hour. It stops abuse, protects your servers and keeps things fair for everyone. Common methods are fixed window, sliding window and token bucket. When a client goes over the limit, answer 429 Too Many Requests with a Retry-After header.25 min
4. Logging and monitoringOnce your app is live, you cannot watch it with your eyes. Logs record what happened, metrics count how the app is doing (requests per second, error rate, slow responses), and traces follow one request through every service. Good teams write structured JSON logs with a request id, never log secrets, add a /health check, and set alerts so a person is told when something breaks.30 min

Prove your backend works and explain it to others: unit tests with edge cases and test doubles, integration tests that send requests in sequence against a fresh store, and clear API docs with OpenAPI, examples, errors and versioning.

1. Unit testing: checking one piece at a timeA test is a small piece of code that runs your code and checks the answer. A unit test checks one small piece, usually one function, with no network and no database, so it runs in milliseconds. Good tests follow Arrange, Act, Assert, have names that explain the rule, and cover the edge cases like empty, zero and negative values.25 min
2. Integration testing: checking parts work togetherAn integration test checks that several parts work together: the route, the handler, the validation and the database. You send real-looking requests one after another (create, then read, then delete) and check every response. Each test starts with fresh data so tests never depend on each other, and they run automatically in CI on every push.25 min
3. Documenting your API with OpenAPIAPI documentation tells other developers what each endpoint does, what to send and what comes back, including errors. The common standard is OpenAPI (formerly called Swagger): one YAML or JSON file that tools like Swagger UI, Redoc and Scalar turn into a readable, clickable website. Good docs also have example requests, a changelog and clear deprecation notices.25 min

Take your backend from your laptop to real users: work on Linux servers, package the app with Docker, deploy to the cloud with HTTPS and zero downtime, scale with load balancers, replicas and CDNs, and plan large systems with numbers instead of guesses.

1. Linux basics for backend developersAlmost every server on the internet runs Linux, and you control it by typing commands in a terminal. A small set of commands lets you move around, read logs, check memory and disk, and restart your app. You log in safely with SSH keys, protect files with permissions like 644 and 755, and let systemd keep your app running.30 min
2. Docker: packaging your appDocker packs your app together with everything it needs (the right Node.js version, libraries, settings) into an image. You run that image as a container, and it behaves the same on your laptop, a test server and production. A Dockerfile is the recipe for the image, and Docker Compose starts your app with Postgres and Redis in one command.30 min
3. Deploying to the cloudThe cloud means renting computers, databases and storage from a company like AWS, Google Cloud or Azure, and paying for what you use. You can rent bare servers (IaaS), give your code to a platform that runs it (PaaS), or run small functions only when called (serverless). A real deploy also needs a domain, HTTPS, production environment variables, a plan for zero-downtime releases and a budget alert.30 min
4. Scaling: handling more usersScaling means handling more users without slowing down. You can buy a bigger server (vertical) or add more servers behind a load balancer (horizontal). Horizontal scaling needs stateless servers, health checks and a plan for the database: read replicas for heavy reading, and a CDN to serve images and files from near the user.30 min
5. System design: planning a big backendSystem design is planning how the parts of a large backend fit together before you build. You start with requirements and rough numbers, then sketch the API, the data model and a diagram, and finally look for bottlenecks. Start with a well-organised single app (a modular monolith), and add queues, caches and separate services only when the numbers show you need them.30 min

See the same API in Node.js, Python, Java, PHP and Go and learn how to pick one stack. Meet the tools beyond REST (GraphQL, WebSockets, Server-Sent Events, webhooks and gRPC), then prepare for backend interviews in India with common questions, a portfolio project and a 30-day plan.

1. Backend languages and frameworksEvery popular backend language can build the same API. Node.js, Python, Java, PHP and Go all receive a request, read it, and send JSON back. They differ in speed, style and where the jobs are. Pick one, learn it deeply, and the ideas carry over to the next one.25 min
2. Beyond REST: GraphQL, WebSockets and webhooksREST covers most APIs, but some jobs need other tools. GraphQL lets the app ask for exactly the fields it needs. WebSockets and Server-Sent Events push live updates like a cricket score. Webhooks let another service, such as a payment gateway, call your server when something happens.30 min
3. Backend interview preparationBackend interviews in India usually have a coding test, a DSA round, a backend fundamentals round, an SQL round, and for experienced people a system design round, followed by HR. You prepare by practising common questions aloud, building one strong project you can explain well, and following a steady revision plan.30 min