How Backend & Databases Works

HTTP (HyperText Transfer Protocol) is the language of the web. Every time you load a page, call an API, or submit a form, your browser or application sends an HTTP request to a server and the server sends back an HTTP response. HTTP is a stateless, text-based protocol built on top of TCP/IP. Understanding HTTP deeply — methods, status codes, headers, caching, connections — is foundational for any backend developer because every API, web framework, and proxy speaks it.

A REST API is a set of rules for how two computers communicate over HTTP. When your app needs data from a server — user profiles, product listings, order history — it sends an HTTP request to a URL endpoint. The server processes it and sends back structured data (almost always JSON). REST is the dominant architectural style for web APIs because it is stateless, cacheable, and maps naturally onto HTTP verbs.

In Java, equals() defines when two objects are considered equal, and hashCode() returns an int used to bucket objects in hash-based collections. They are bound by a contract: equal objects must have equal hash codes. Break it and HashMap, HashSet, and Hashers silently misbehave — losing entries or storing duplicates. Understanding this contract is essential for correct domain objects and a favourite interview topic.

The Stream API (Java 8+) lets you process collections declaratively: describe what you want — filter these, transform those, collect the rest — instead of writing loops. A stream is a pipeline of operations over a data source. Intermediate operations like map and filter are lazy and build the pipeline; a terminal operation like collect or forEach triggers execution. Done right, streams are more readable than loops and can go parallel with a single method call.

Records (Java 16) and sealed classes (Java 17) modernise how you model data in Java. A record is a compact, immutable data carrier: you declare the fields once and the compiler generates the constructor, accessors, equals, hashCode, and toString. A sealed class or interface restricts which types may extend it, giving you a closed set of subtypes. Together with pattern matching, they let you model a domain precisely and handle every case exhaustively.

Java has evolved fast since the six-month release cadence began. Java 8 introduced lambdas and streams; the LTS releases 11, 17, and 21 layered on var, switch expressions, text blocks, records, sealed classes, pattern matching, and virtual threads. Knowing which feature arrived when — and why — lets you write cleaner, safer modern Java and answer a common interview question about version differences.

Spring Boot is annotation-driven: small markers on classes and methods tell the framework how to wire, expose, and manage your code. Instead of XML configuration, you sprinkle @Service, @RestController, and @Autowired and Spring does the rest. Knowing what the everyday annotations actually do — and which are compositions of others — turns Spring from magic into something you can reason about.

SQL (relational) databases store data in tables of rows and columns with a fixed schema, linked by relationships and queried with joins — great for structured data and strong consistency. NoSQL is an umbrella for non-relational stores (document, key-value, wide-column, graph) that trade rigid schemas and joins for flexibility and horizontal scale. Neither is universally better: the right choice depends on your data shape, query patterns, and consistency and scaling needs.

A join combines rows from two or more tables based on a related column. Because relational databases split data across tables to avoid duplication, joins are how you stitch it back together — an order with its customer, a user with their posts. The join type (INNER, LEFT, RIGHT, FULL) decides which rows survive when there is no match. Understanding joins is fundamental to writing correct SQL and to reading query plans.

Normalization is the process of structuring relational tables to reduce redundancy and prevent data anomalies. You split data into related tables so each fact is stored exactly once, then link them with keys. The normal forms (1NF, 2NF, 3NF) are progressive rules for doing this well. Normalization keeps data consistent and easy to update; denormalization deliberately reverses some of it to speed up reads when needed.

MongoDB is a document database: instead of rows in tables, it stores flexible, JSON-like documents in collections. Each document can have its own shape, so you can embed related data together and read an entire object in one query — no joins. MongoDB scales horizontally with sharding, stays available with replica sets, and offers rich queries and an aggregation pipeline. It suits flexible or rapidly-evolving data where access is mostly by a known key or embedded structure.

Publish-subscribe (pub/sub) is a messaging pattern where senders (publishers) do not send messages to specific receivers. Instead they publish to a topic, and every subscriber to that topic receives a copy. Publishers and subscribers never know about each other — they are decoupled through the topic. This fan-out delivery makes pub/sub ideal for broadcasting events to many independent consumers, the backbone of event-driven architectures.

Server-Sent Events (SSE) let a server push a continuous stream of updates to a browser over a single, long-lived HTTP connection. Unlike WebSockets, SSE is one-way (server to client only) and rides on plain HTTP, which makes it simple to build and firewall-friendly. The browser EventSource API handles the connection, parses the text/event-stream format, and automatically reconnects if the connection drops — ideal for notifications, live feeds, and progress updates.

Becoming a backend developer is about learning a coherent stack in a sensible order, not collecting random tools. In 2026 the path is: master one language plus data structures and algorithms, then databases, then how to build and secure APIs, then system design to reason about scale, then DevOps to ship and run your work, and finally the AI-for-backend skills that are now expected. Depth in fundamentals beats breadth in trendy frameworks — the fundamentals transfer, the frameworks change.

Clean code is code that is easy to read, understand, and change — because code is read far more often than it is written. The principles are practical: use clear, intention-revealing names; keep functions small and focused on one thing; avoid duplication (DRY); prefer simple, obvious solutions over clever ones; and let the code explain itself so comments are rarely needed. Clean code is not about aesthetics — it is about lowering the cost of maintenance and reducing bugs over the life of a system.

Code review is the practice of having other engineers examine a change before it merges. Through a pull request, the author proposes a change, reviewers read it, ask questions, and suggest improvements, and once approved it merges. Done well, code review catches bugs early, keeps quality and consistency high, and — crucially — spreads knowledge across the team. Its effectiveness depends as much on culture and communication as on technical rigor: small changes, kind and specific feedback, and a shared goal of improving the code, not judging the author.

Good technical documentation helps someone accomplish a task without needing to ask you. Engineers often treat docs as an afterthought, but clear documentation multiplies a team productivity — it onboards new people, reduces repeated questions, and preserves knowledge. The essentials: know who you are writing for and what they need to do, structure it so readers can scan and find answers, include working examples, explain the why behind decisions, and keep it up to date so it stays trustworthy. Writing docs is a core engineering skill, not a side chore.

Behavioral interviews ask how you have acted in past situations to predict how you will act in the future — "tell me about a time you had a conflict," "describe a project that failed." The STAR method gives you a structure to answer clearly: Situation (the context), Task (your responsibility), Action (what you specifically did), and Result (the outcome). Interviewers assess collaboration, ownership, communication, and how you handle difficulty. Preparing a handful of strong, specific stories in advance is the single best way to do well.

A relational database like PostgreSQL is a sophisticated engine that takes a SQL query, figures out the most efficient way to fetch data, retrieves it from disk pages, ensures multiple users can work simultaneously without corrupting each other's data, and guarantees that even a power failure won't corrupt your records. Understanding these internals is the difference between writing queries that take 2ms and ones that take 20 seconds.

A database index is a separate data structure that lets the database find rows matching a condition without scanning every row in the table. The default index type — the B-tree — stores column values in a balanced tree so any value can be found in O(log n) comparisons. A table with 100 million rows can be searched in roughly 27 comparisons with an index, versus 100 million comparisons without one. Understanding indexes is the single highest-leverage skill for database performance.

A database transaction is a sequence of operations that executes as a single unit: either all operations succeed and are committed to disk, or all are rolled back as if nothing happened. Transactions protect your data from partial failures (a server crash mid-transfer) and concurrent access problems (two users modifying the same row simultaneously). The ACID properties define exactly what guarantees a transaction provides, and isolation levels let you trade consistency for performance depending on what your application can tolerate.

Redis is an in-memory data structure store that can act as a cache, message broker, session store, rate limiter, and real-time leaderboard — all at the same time. Because it stores everything in RAM and uses a single-threaded event loop, Redis can handle over 1 million operations per second on a single instance. It's one of the most widely deployed pieces of infrastructure in the world — used by Twitter, GitHub, Airbnb, and almost every large backend system.

A message queue is a buffer that sits between two services, letting them communicate without being directly connected or even running at the same time. Instead of Service A calling Service B directly (tight coupling), A drops a message into the queue and moves on. B reads the message when it's ready. This pattern is the backbone of every large-scale distributed system — it enables decoupling, async processing, load smoothing, and fault tolerance all at once.

Apache Kafka is a distributed event streaming platform. Unlike traditional message queues that delete messages after delivery, Kafka stores messages durably as an ordered, immutable log — and any number of consumers can read the same log independently at their own pace. This design makes Kafka ideal for event-driven architectures, real-time data pipelines, and microservice communication at scale. Kafka can sustain millions of messages per second across a cluster while maintaining durability guarantees.

The Java Virtual Machine (JVM) is what makes Java "write once, run anywhere." Your source code compiles to bytecode — a platform-neutral instruction set — and the JVM interprets and compiles that bytecode at runtime for whatever OS and CPU the code is actually running on. The JVM also manages memory automatically through garbage collection, optimises hot code paths using a Just-In-Time (JIT) compiler, and isolates each application in its own managed runtime.

Spring Boot is an opinionated wrapper around the Spring Framework that eliminates XML configuration and gets you to a running production-ready service in minutes. At its core, Spring Boot works by scanning your classpath at startup, detecting what libraries you have (Hibernate on the classpath? Configure a DataSource automatically), and wiring up everything your application needs without you writing a single line of boilerplate config. The magic is auto-configuration: hundreds of @Configuration classes that activate conditionally based on what you have in your project.

Git is not a file system tracker — it is a content-addressable key-value store. Every file, directory snapshot, and commit is stored as an immutable object identified by a SHA-1 hash of its contents. Branches are simply files containing a 40-character hash. When you understand Git's four object types and how they link together, every Git command — commit, branch, merge, rebase, reset, cherry-pick — becomes predictable. Nothing in Git is as magical (or as scary) as it first appears.

Garbage collection (GC) is how the JVM automatically frees memory you no longer use. Instead of calling free() like in C, you just stop referencing an object and the collector reclaims it. Modern JVMs use generational collection — most objects die young, so the heap is split into a Young Generation (collected often and fast) and an Old Generation (collected rarely). Collectors like G1GC, ZGC, and Shenandoah trade throughput against pause time, letting you tune Java for either batch jobs or ultra-low-latency APIs.

Virtual threads, delivered in Java 21 via Project Loom, are lightweight threads managed by the JVM rather than the operating system. A traditional platform thread maps 1:1 to an OS thread and costs ~1MB of stack, so a server can run only a few thousand. Virtual threads are cheap — you can have millions. When a virtual thread blocks on I/O, the JVM unmounts it from its carrier (a real OS thread) and runs another, so the simple thread-per-request style finally scales without reactive complexity.

Concurrency lets a program make progress on multiple tasks at once. In Java, that means threads sharing memory — which is powerful but dangerous: two threads touching the same data without coordination cause race conditions. Java gives you a toolbox to coordinate safely: synchronized and locks for mutual exclusion, volatile for visibility, atomic classes for lock-free counters, and high-level executors and CompletableFuture so you rarely manage raw threads yourself.

A HashMap stores key-value pairs and gives you average O(1) get and put. It does this with an array of buckets: the key hashCode is spread and mapped to a bucket index, and the entry is stored there. When multiple keys land in the same bucket (a collision), they form a linked list — and since Java 8, a bucket with too many entries converts to a balanced red-black tree so lookups stay fast even under heavy collisions.

Dependency injection (DI) is the core of Spring. Instead of your classes creating their own collaborators with new, Spring creates and supplies them for you. The Inversion of Control (IoC) container scans your code, builds a graph of beans (managed objects), and injects each bean where it is needed. This decouples your classes, makes them testable, and centralises configuration — the reason Spring code has almost no new keywords for services.

Spring Data JPA removes the boilerplate of data access. You declare a repository interface — no implementation — and Spring generates one at runtime that talks to the database through JPA and Hibernate. Method names like findByEmailAndActiveTrue are parsed into queries automatically, and you get CRUD, paging, and sorting for free. It is one layer above JPA: JPA defines the mapping, Hibernate executes it, Spring Data wires it into clean repositories.

Hibernate is an object-relational mapping (ORM) framework: it maps your Java objects to database tables so you work with objects instead of SQL. Behind the scenes it maintains a persistence context — a per-transaction cache of managed entities — tracks changes via dirty checking, and flushes the right SQL at the right time. Its power (lazy loading, caching, automatic updates) is also its danger: misused, it causes the infamous N+1 query problem.

A transaction groups database operations so they all succeed or all fail — the "A" in ACID. In Spring you rarely manage this by hand: annotating a method @Transactional tells Spring to start a transaction before it runs, commit if it returns normally, and roll back if it throws. Spring implements this with a proxy around your bean, which is why a few well-known rules — public methods, no self-invocation, correct rollback config — decide whether it actually works.

Spring Security protects your application by inserting a chain of servlet filters in front of your controllers. Every request passes through these filters, which authenticate the caller (who are you?) and authorize the request (are you allowed?). It stores the authenticated identity in a SecurityContext, supports many mechanisms — form login, HTTP Basic, JWT, OAuth2 — and lets you secure endpoints declaratively. Understanding the filter chain demystifies the whole framework.

Opening a database connection is expensive: a TCP handshake, authentication, and session setup can take milliseconds each — an eternity if you do it per request. A connection pool keeps a set of open connections ready and hands them out on demand, returning them to the pool when done. This turns a costly setup into a cheap borrow-and-return, and it caps how many connections hit the database at once. HikariCP is the fast, default pool in Spring Boot.

GraphQL is a query language for APIs where the client asks for exactly the data it needs — no more, no less — from a single endpoint. Instead of many REST URLs, a GraphQL server exposes one endpoint and a typed schema describing what can be queried. Clients send a query shaped like the response they want, and resolver functions on the server fetch each field. This eliminates over- and under-fetching, at the cost of new concerns like query complexity and caching.

Spring Boot, Quarkus, and Micronaut are all Java frameworks for building backend services, but they make a key architectural choice differently. Spring Boot wires beans at runtime using reflection; Quarkus and Micronaut do most of that work at compile time, producing apps that start in milliseconds, use less memory, and compile cleanly to GraalVM native images. Spring Boot leads on ecosystem and maturity; the newer frameworks lead on cloud-native startup and footprint.

PostgreSQL is a powerful open-source relational database known for correctness and features. Under the hood it uses MVCC (Multi-Version Concurrency Control) so readers never block writers, a write-ahead log (WAL) to guarantee durability and enable replication, and a cost-based query planner that chooses how to execute your SQL. Understanding these pillars — plus indexes and VACUUM — explains most of Postgres behaviour and performance.

ACID and BASE are two philosophies for database consistency. ACID (Atomicity, Consistency, Isolation, Durability) guarantees transactions are all-or-nothing and always leave the data valid — the model of relational databases. BASE (Basically Available, Soft state, Eventually consistent) relaxes those guarantees to maximise availability and scale — the model many distributed NoSQL systems adopt. Neither is better; they sit at opposite ends of a consistency-versus-availability spectrum.

A B-tree index is the data structure behind almost every database index. It is a balanced tree that keeps keys sorted and lets the database find, insert, and delete rows in logarithmic time — turning a full-table scan into a handful of page reads. Its shallow, wide shape (the B+tree variant links leaves together) makes both single-key lookups and range scans fast, which is why B-trees are the default index in PostgreSQL, MySQL, and most databases.

When two transactions update the same row at once, one update can silently overwrite the other — the lost-update problem. Locking prevents it. Pessimistic locking assumes conflict is likely and locks the row up front so others must wait. Optimistic locking assumes conflict is rare, lets everyone proceed, and detects a clash at write time using a version column — failing the loser so it can retry. Choosing between them is about how much contention you expect.

Replication keeps copies of your database on multiple servers. The most common setup is primary-replica: one primary handles writes and streams its changes to read replicas that serve read queries. This scales reads, provides high availability (a replica can be promoted if the primary fails), and enables geographic distribution. The key trade-off is replication lag — asynchronous replicas can briefly serve slightly stale data.

RabbitMQ is a message broker that reliably routes messages between services. Producers do not send messages directly to queues — they publish to an exchange, which routes copies to one or more queues based on rules called bindings. Consumers read from queues and acknowledge messages once processed. This exchange-binding-queue model, plus acknowledgements and persistence, lets RabbitMQ decouple services and guarantee messages are not lost.

Kafka and RabbitMQ both move messages between services, but they are built on different models. RabbitMQ is a traditional message broker: it routes messages through exchanges to queues, tracks delivery, and removes a message once consumed. Kafka is a distributed, append-only log: it retains messages for a configured time, and consumers track their own position (offset), so many consumers can read — and re-read — the same stream. This shapes when each excels.

gRPC is a high-performance framework for service-to-service calls. You define a service and its messages in a .proto file using Protocol Buffers; a compiler generates strongly-typed client and server code in many languages. Calls travel over HTTP/2 as compact binary Protobuf, which is far smaller and faster than JSON. gRPC also supports streaming — client, server, and bidirectional — making it a favourite for internal microservice communication where performance and strict contracts matter.

WebSockets provide a persistent, two-way connection between a client and server over a single TCP connection. A normal HTTP request-response cannot push data to the client; the client must keep asking. WebSockets solve this: after an HTTP handshake that "upgrades" the connection, both sides can send messages any time (full-duplex) with very low overhead. They power real-time features — chat, live dashboards, multiplayer games, collaborative editing.

When a system delivers messages, it makes one of three guarantees. At-most-once may lose messages but never duplicates. At-least-once never loses messages but may deliver duplicates. Exactly-once delivers each message once and only once — the ideal, but genuinely hard in a distributed system with failures and retries. In practice, most systems use at-least-once delivery plus idempotent consumers to achieve effectively-exactly-once results.

A dead letter queue (DLQ) is a separate queue where messages go when they cannot be processed successfully — after exhausting retries, expiring, or being rejected. Without a DLQ, a single unprocessable "poison" message can be retried forever, blocking the queue and burning resources. The DLQ moves it aside so healthy messages keep flowing, and gives you a place to inspect what failed, fix the cause, and replay the messages once resolved.

Most coding-interview problems are variations of a small set of recurring patterns. Instead of memorising hundreds of solutions, you learn to recognise the pattern behind a problem and apply the right technique. The essential patterns include two pointers, sliding window, binary search, BFS and DFS for trees and graphs, dynamic programming, and heaps/priority queues. Once you can map a new problem to a known pattern, you go from staring blankly to knowing exactly how to start — which is the real skill interviews test.

A well-designed REST API is predictable, consistent, and easy to consume. The core ideas: model your API around resources (nouns), use HTTP methods and status codes correctly, keep naming and responses consistent, and handle the real-world concerns — errors, pagination, filtering, versioning, and idempotency. Good design is not about clever tricks; it is about following widely-understood conventions so any developer can guess how your API behaves and integrate quickly.

API versioning lets you evolve an API without breaking the clients that depend on it. Once external consumers rely on your responses, you cannot freely change them — a removed field or altered shape breaks integrations. Versioning gives you a way to introduce breaking changes in a new version while keeping the old one working. The main strategies are URL-path, query-parameter, custom-header, and media-type versioning. Equally important is minimising breaking changes in the first place and having a clear, communicated deprecation path.

SOLID is a set of five object-oriented design principles that make software easier to maintain, extend, and test. They are: Single Responsibility (a class has one reason to change), Open/Closed (open for extension, closed for modification), Liskov Substitution (subtypes must be usable in place of their base type), Interface Segregation (many small interfaces beat one fat one), and Dependency Inversion (depend on abstractions, not concretions). Applied well, they reduce coupling and make change safe.

The Java Memory Model (JMM) defines when a value written by one thread is guaranteed to be visible to another. Modern CPUs and compilers reorder and cache operations for speed, so without rules a thread could see stale or half-constructed data. The JMM gives you the happens-before relationship: a set of guarantees (via volatile, synchronized, locks, and thread lifecycle) that establish ordering and visibility so concurrent programs behave predictably.

A ClassLoader is the part of the JVM that finds and loads .class files into memory on demand. Rather than one loader, the JVM uses a hierarchy — bootstrap, platform, and application loaders — connected by parent-first delegation, which protects core classes from being replaced. Custom class loaders power plugin systems, application servers, and hot reloading, but they are also the source of a notorious kind of memory leak.

Spring WebFlux is the reactive, non-blocking alternative to Spring MVC. Instead of assigning one thread per request and blocking it during I/O, WebFlux runs on a small event loop and represents results as asynchronous streams — Mono (0 or 1 value) and Flux (0 to many). When work is waiting on I/O, the thread is freed to serve others, so a few threads handle enormous concurrency. The trade-off is a steeper mental model and the need for non-blocking libraries end to end.

Sharding splits one large dataset across multiple database servers, each holding a subset of the rows. When a single machine can no longer handle the data volume or write throughput, sharding scales the database horizontally. A shard key decides which server owns each row. The payoff is near-unlimited scale; the cost is complexity — cross-shard queries, transactions, and rebalancing all become harder, so sharding is a last resort after simpler options.

Kafka Streams is a library for building real-time applications that transform data flowing through Kafka. Instead of a separate cluster, it runs inside your normal Java application, reading from input topics, processing records as they arrive, and writing to output topics. It supports both stateless operations (filter, map) and stateful ones (aggregations, joins) backed by local state stores, plus time windowing and exactly-once processing — turning Kafka from a pipe into a processing engine.

Change Data Capture (CDC) streams every insert, update, and delete from a database to other systems in near real time. Instead of polling for changes, log-based CDC reads the database transaction log (Postgres WAL, MySQL binlog) — the same log used for replication — and emits a change event per row change. Tools like Debezium publish these to Kafka, so caches, search indexes, data warehouses, and microservices stay in sync without the database even knowing they exist.