The client consumes resources and initiates contact in the basic request-response model. The server provides resources, listens for incoming requests, and responds. Multiple clients can connect to the same server simultaneously; server-initiated updates require an established channel or an extra mechanism such as WebSockets, server-sent events, or push notifications.

In P2P, there is no central server. Every node is equally privileged and acts as both a supplier and consumer of resources. It is decentralized, so there is no single point of failure — but if a peer goes offline, its unique resources become unavailable.

A hybrid combines client-server and P2P. Apple FaceTime uses hybrid: for 1-on-1 calls it attempts a direct P2P connection for lower latency, falling back to Apple’s relay servers if NAT or firewalls block the direct path. Group FaceTime routes all participants through Apple’s servers to prevent each device from uploading a separate video stream to every other participant.

Throughput = volume of requests processed per unit time (e.g., an API handling 500 req/sec during peak load). Latency = time for a single request to complete (e.g., a database query returning in 40ms). They are not always correlated: adding more servers increases throughput but doesn’t reduce per-request latency. Caching reduces latency and may also increase throughput.

1. Application Layer — your browser constructs the HTTP request (verb, URL, headers). 2. Transport Layer — TCP wraps it in a segment with port numbers and sequence info for reliable delivery. 3. Internet Layer — IP wraps it in a packet with source and destination IP addresses for routing between networks. 4. Link Layer — Ethernet/Wi-Fi wraps it in a frame with MAC addresses and physically transmits it to the next hop.

Each layer wraps the higher-layer message as its payload and adds its own header — like sealing a letter inside successively larger envelopes. An HTTP message (the letter) is placed inside a TCP envelope (labeled with port numbers), which is placed inside an IP envelope (labeled with IP addresses), which is placed inside an Ethernet envelope (labeled with MAC addresses). Each envelope carries only the addressing information needed for that one delivery step.

SYN → SYN-ACK → ACK. The client sends SYN (‘I want to connect’), the server replies SYN-ACK (‘OK, I’m ready’), the client confirms with ACK (‘let’s go’). It ensures both parties are ready to send and receive data before any data is transmitted.

TCP sends data in ordered segments with checksums for error detection. The receiver sends ACKs to confirm receipt (a single ACK can cover multiple segments). If the sender doesn’t receive an ACK within a timeout, it retransmits the missing data. This provides reliable, in-order byte-stream delivery while the connection remains usable; applications still need their own checks for end-to-end business invariants.

Each HTTP request is independent — the server does not remember any information about previous requests from the same client. Every request must contain all the information the server needs to respond. Web apps use cookies/sessions to maintain state across requests.

GET — retrieve a resource. POST — send data for processing, typically to create a new resource. PUT — create or replace the resource at a specific URI (idempotent). DELETE — delete a resource. HEAD — retrieve only the headers of a resource (not the body).

Localhost — a special reserved IP address that always refers to your own machine. During development you might run your Express backend on localhost:5000 and your React frontend on localhost:3000; both processes are on the same machine and communicate without ever touching the public internet.

{protocol}://{domain}(:{port})(/{resource}). Example: http://localhost:5000/courses/cs101. Protocol (http/https), domain (the server’s address), port (which application on the server — optional, defaults to 80/443), resource path (which resource to access — optional, defaults to /).

HTTPS adds TLS encryption, integrity protection, and server authentication to HTTP. It protects sensitive data (passwords, personal info) from being read or modified in transit. Modern web guidance is to serve public pages and subresources over HTTPS, even when the page itself is not collecting sensitive data.

(1) Partial writes on crash. (2) Concurrent access — two writers corrupting each other. (3) Hardware loss — disk failure destroying the only copy. (4) Scale — slow linear scans over growing data. A DBMS solves each of these once instead of re-solving them in every application.

You describe what data you want; the DBMS decides how to get it — which indexes to use, which order to join tables in, how to parallelize. This separation lets the DBMS optimize a query without the programmer rewriting it, and lets the same query keep working as data grows or schemas change.

An ER (Entity-Relationship) diagram depicts the things in the world the system must represent and how they relate. The standard notation uses rectangles for entities (things: Student, Course), ovals for attributes (what we know about them: name, UID), and diamonds for relationships between entities (is enrolled).

N to M means many-to-many: many entities on each side can be associated with many on the other (one student takes many courses; one course has many students). Many-to-many cannot be stored as a single foreign-key column — it forces the introduction of a join table (also called a bridge or associative table), typically with a composite primary key from the two foreign keys.

A primary key is a column (or combination of columns) that uniquely identifies a row within a table. A foreign key is a column whose values must match some row’s primary key in another table, keeping cross-table references valid. Primary keys are about intra-table uniqueness; foreign keys are about inter-table referential integrity.

When no single column is unique on its own, but a combination is. Example: in an Enrollment(student_id, course_id, quarter) table, neither student_id nor course_id alone is unique (a student takes many courses; a course has many students). The unique combination — the triple (student_id, course_id, quarter) — is the primary key.

Join (⋈) — combine rows from two tables that match on a key. Selection (σ) — keep only rows that satisfy a condition (filter rows). Projection (Π) — keep only specified columns (drop columns). Group-By (γ) — partition rows into groups and compute an aggregate (COUNT, SUM, AVG, …) per group.

JOIN → Join (⋈); WHERE → Selection (σ); the column list in SELECT → Projection (Π); GROUP BY (plus aggregates) → Group-By (γ).

A sequence of database operations treated as a single atomic unit of work. Either all of the operations are applied (the transaction commits) or none of them are (it is rolled back). From outside, a transaction looks instantaneous — intermediate states are invisible to other transactions.

COMMIT tells the DBMS to make all the transaction’s changes permanent and visible. ROLLBACK tells it to discard all of the transaction’s changes, leaving the database exactly as it was before the transaction started. A crash before COMMIT is equivalent to ROLLBACK.

A — Atomicity: all operations in a transaction succeed, or none do. C — Consistency: committed transactions never violate declared constraints. I — Isolation: concurrent transactions behave as if they were serialized, not interleaved. D — Durability: once committed, changes survive any subsequent crash.

Atomicity protects against partial writes — a crash mid-transaction leaving half-applied state. Consistency protects against invalid data — constraint violations (negative balances, dangling foreign keys). Isolation protects against concurrency anomalies — lost updates, phantom reads, inconsistent snapshots. Durability protects against losing acknowledged writes to a power or process failure.

Consistency (C) — every read returns the most recent committed write (or an error). This is linearizability, not the ACID-C of constraint preservation. Availability (A) — every request receives a (non-error) response, though not necessarily the latest data. Partition Tolerance (P) — the system keeps functioning even when the network between its nodes drops or delays messages arbitrarily.

When a network partition occurs in a distributed system, the system must sacrifice either Consistency or Availability — it cannot keep both. Networks do partition in practice, so P is effectively mandatory, and the real operational choice is CP (refuse requests during a partition to stay correct) vs. AP (keep serving, accept staleness).

A CP system refuses requests on the side of a partition that cannot reach the majority of replicas, to avoid stale reads. Example: majority-write MongoDB, HBase, ZooKeeper, classical RDBMS with synchronous replication. An AP system keeps serving on both sides, accepting that reads may be stale until the partition heals. Example: Amazon DynamoDB (default), Apache Cassandra, CouchDB, Riak.

Eventual consistency guarantees that if no new writes occur, all replicas will eventually converge to the same state — but gives no bound on when. It is the typical consistency model of AP systems: during a partition, replicas diverge; after the partition heals, they reconcile.

Because the two mean different things: ACID-C = declared schema constraints are never violated by a committed transaction (a property of a single logical database). CAP-C = every read returns the latest written value across replicas (a property of a distributed system). A relational DBMS with asynchronous replication honors ACID-C on the primary yet still serves stale reads from replicas — violating CAP-C. ‘Strongly consistent because we use SQL’ confuses the two.

ATMs are AP with eventual consistency, not a system that defies CAP. During a WAN outage to the bank, many ATMs continue to allow withdrawals up to a cached daily limit, and the resulting transactions are reconciled once the link returns — sometimes producing temporary overdrafts that the bank absorbs. ATMs demonstrate a deliberate Availability-over-Consistency business choice: staying open is worth occasional post-hoc reconciliation cost.

Document (MongoDB, CouchDB) — nested JSON-like records; good for content with optional or variable fields. Key-value (Redis, DynamoDB, Riak) — simple key → value lookups; good for caches, session stores. Wide-column (Cassandra, HBase, ScyllaDB) — rows with families of sparse columns; good for time-series and very-wide denormalized data. Graph (Neo4j, Neptune, JanusGraph) — nodes and typed edges; good for social graphs, fraud detection, knowledge graphs.

It emerged (c. 2008–2012) against two constraints of traditional RDBMSs: strict schemas that do not fit rapidly-changing or semi-structured data, and ACID across many nodes becoming expensive in distributed settings. It was later redefined as ‘Not Only SQL’ — many NoSQL systems have their own query languages and some even support SQL-like syntax. The name is about dropping the relational assumption, not about banning SQL.

RDBMS: well-structured data with cross-row invariants, where multi-row ACID transactions, referential integrity, and joins matter (finance, bookings, inventory of record). NoSQL: large, loosely-structured data where flexible schemas, horizontal scale, and availability matter more than strict consistency and transactional joins (feeds, catalogs, logs, caches).

The ISO/IEC 9075 core of SQL (basic DML/DDL, joins, group-by) is largely portable — but real applications rely on vendor-specific extensions: stored-procedure languages (PL/pgSQL vs. T-SQL vs. PL/SQL), window-function dialects, JSON operators, types, indexes, extensions. Migration of a non-trivial application across dialects almost always takes real engineering effort.

(a) Never double-spend money → Consistency (CP). (b) Stale reads are fine; a 500 error is expensive → Availability (AP). (c) Globally distributed service must survive transcontinental network failures → Partition Tolerance (mandatory, combine with CP or AP as the application allows). (d) ATM dispensing cash during a bank-link outage → Availability (AP) with later reconciliation.

Confidentiality — sensitive data is accessible to authorized users only. Integrity — sensitive data can be modified by authorized users only, and stays accurate, consistent, and trustworthy over its lifecycle. Availability — critical services are reachable when legitimate clients need them.

Confidentiality — sensitive data is now accessible to whoever holds the laptop, who is not an authorized user. Integrity and Availability are not affected on the original system.

Integrity — the on-disk bytes have been overwritten with attacker-controlled ciphertext, an unauthorized modification. Availability — the legitimate users can no longer read their data. (Pure ransomware does not violate Confidentiality; modern ‘double-extortion’ ransomware that also exfiltrates would add a confidentiality violation.)

SQL injection is an attack where user-supplied input is concatenated into a SQL query string and ends up being interpreted as SQL syntax instead of as a value. The underlying cause is mixing code and data — the database’s parser cannot tell which characters came from the developer’s query template and which came from the user.

Use parameterized queries / prepared statements: write the SQL with placeholders (?, @0, $1, …) and pass the values as separate arguments to the database driver. This works because the database parses the SQL once with the placeholders in place before the values are ever attached, so the values cannot grow new SQL syntax — they are bound into an already-parsed query plan as pure data.

All three: Confidentiality (read sensitive rows from any table the connection can see), Integrity (modify, insert, or delete data — UPDATE … SET role='admin', INSERT a backdoor account, DROP TABLE), and Availability (less common, but possible — drop tables, delete rows, or run very expensive queries to exhaust the database).

XSS is an attack where user-supplied content is interpolated into an HTML page and ends up being interpreted by the browser as HTML/JavaScript. The underlying cause is the same as SQLi — mixing code and data — but the downstream interpreter is the browser, not the database. The injected script runs in the trusted site’s origin, so it can read cookies, the DOM, and issue authenticated requests.

(1) Output encoding — escape HTML metacharacters (< → <, > → >, " → ", & → &) when rendering user content. Modern templating engines (React JSX, Vue {{ }}, Django, Jinja2) escape by default. (2) Content Security Policy (CSP) — an HTTP header that restricts which script sources the browser will execute, defending in depth even if encoding fails. (3) HttpOnly cookies for session tokens — so a successful XSS cannot directly read the token.

Confidentiality (script reads cookies, tokens, DOM contents, and exfiltrates them) and Integrity (script modifies the page, submits forms in the victim’s name, posts on their behalf, changes settings). Availability violations are possible (a runaway script can wedge a browser tab) but uncommon in practice.

Symmetric encryption uses the same secret key to both encrypt and decrypt. The most widely used algorithm today is AES (with 128-, 192-, or 256-bit keys). Symmetric ciphers are fast and well-suited to bulk data, but their main weakness is the key-distribution problem: sender and receiver must agree on the key without an attacker overhearing — and if they had a private channel for that, they would not need encryption.

Public-key cryptography generates a pair of mathematically linked keys: a public key that anyone may have, and a private key kept secret by the owner. A message encrypted with one key of the pair can only be decrypted by the other key. To send Alice a private message, Bob encrypts with Alice’s public key — only her private key can decrypt it. No prior shared secret is needed; Alice’s public key can be published freely.

Bob’s public key. Anyone may have it, so Alice can use it without prior secret sharing — but only Bob’s matching private key (which only Bob holds) can decrypt the resulting ciphertext.

A digital signature proves that a document was produced by the holder of a particular private key, and that the document has not been altered. The signer (1) computes a cryptographic hash of the document (SHA-256, e.g.); (2) encrypts the hash with their private key — that encrypted hash is the signature. To verify, anyone with the document, the signature, and the signer’s public key decrypts the signature, recomputes the hash from the document, and checks the two match.

Performance. Public-key operations are roughly three orders of magnitude slower per byte than a fast hash like SHA-256. Hashing reduces every document — regardless of size — to a fixed-length digest (32 bytes for SHA-256), so the slow public-key operation runs over those 32 bytes instead of the whole document. The hash’s collision-resistance also means an attacker cannot construct a different document with the same hash and therefore the same signature.

(1) Slow — the server must verify the password (with a deliberately slow hash like bcrypt or Argon2) on every request, adding tens of milliseconds of CPU per call. (2) Insecure — the cleartext password lives in the client’s memory for the lifetime of the session and crosses the network on every request, multiplying the chances of leaking via a log file, debug trace, or proxy header.

After successful login, the server generates a random opaque session ID mapping to the user, stores it in a server-side session store, and returns it to the client in a cookie. The browser automatically attaches the cookie to every subsequent request to the same domain. Three hardening flags: HttpOnly (cookie not readable from JavaScript), Secure (cookie only sent over HTTPS), SameSite=Strict or Lax (cookie not attached to cross-site requests, defending against CSRF).

A JWT is a small encoded JSON document — typically { sub: <user-id>, exp: <expiry>, … } — digitally signed by the server’s key. The client attaches it to every request (in an Authorization: Bearer … header or in a cookie). The server verifies the signature with its own key and trusts the claims without consulting any database. Unlike a session cookie, there is no server-side session store; the JWT is the session, and the signature is what makes it forgery-proof.

Session cookies: stateful (need a session store), easy to revoke (delete the row), simple. JWTs: stateless on the server (no session store; easier horizontal scaling), but harder to revoke (a stolen JWT stays usable until exp). Both are vulnerable to XSS-driven session-riding; both should be served only over TLS. JWTs in localStorage are XSS-readable (avoid). JWTs in HttpOnly + SameSite cookies match the session-cookie security profile.

No. HttpOnly prevents JavaScript from reading the cookie, so a successful XSS attack cannot directly exfiltrate the session token. But the script can still use the session: any fetch('/api/...', { credentials: 'include' }) call will have the cookie attached automatically by the browser, so the attacker rides the session in the victim’s browser without ever touching the raw token. This is sometimes called session-riding.

Zero Trust says users and devices should not be trusted by default — every request must be authenticated and authorized regardless of where it originates, and every input must be validated and sanitized regardless of its source. Operational consequence: draw the trust boundary tightly. Inputs from end users, third-party APIs, file uploads, configuration files, and even other internal services must be validated at the boundary they cross into your code.

Security through obscurity is the practice of relying on hiding the design or mechanism of a system to keep it secure (a hidden URL, a custom-rolled hash, an unpublished port). It is a bad foundation because as soon as anyone reverses or discovers the design, the entire defense collapses — the lecture’s analogy is hiding the house key in a flowerpot. Real security must rest on something that stays secret even when the design is public — typically a key — which is what the Open Design principle requires.

Public scrutiny when proposing a new security approach or algorithm — expose the design to the security community so weaknesses are found before attackers exploit them. Complementary obscurity when deploying an existing, well-scrutinized technology in a real product — hide implementation specifics (framework versions, configuration, internal endpoints) to slow down opportunistic attackers who look for known vulnerabilities. The two apply to different layers and are not contradictory.

Principle of Least Privilege: every program and every privileged user of the system should operate using the least set of privileges necessary to complete its job. Concrete application: split a monolithic app into small components, each with narrowly scoped permissions — the email-notification service holds only the email-API credential, the image-upload service holds only write access to the upload bucket. If one component is compromised, the blast radius is limited to what that component’s credentials can do.

(1) Security model — what are you defending? (assets: data, services, secrets, reputation). (2) Threat model — who might be attacking, and what are they trying to achieve? (3) Attack surface — which parts of the system are exposed to an attacker? (4) Protection mechanisms — how do we prevent (or detect) compromise?

(1) Knowledge — what does the attacker already know? (Public docs only? Stolen source code? Insider with credentials?) (2) Actions — what can they actually do? (Send web requests? Run code on a guest VM? Tap the network?) (3) Resources — how much time, money, and infrastructure can they spend? (Bored teenager? Criminal cartel? Nation-state?) (4) Incentive — why do they want to compromise the system? (Financial gain? Espionage? Vandalism?)

The attack surface is the set of inputs, endpoints, ports, and side channels through which an attacker could plausibly interact with the system — every public API, every form field, every file path, every network port, every dependency. Shrinking it matters because every exposed surface is a place a vulnerability could live. The fewer surfaces, the fewer things to defend, the fewer things to test, and the smaller the chance of an unmonitored entry point.

Because XSS gives the attacker code execution inside the trusted page’s origin. Even though the script cannot read the cookie (thanks to HttpOnly), it can still issue authenticated fetch requests through the browser — the browser will attach the cookie automatically. So the attacker rides the session in the victim’s browser without ever touching the raw token. This is sometimes called session-riding.

Authenticity is the property that a message can be reliably attributed to a particular sender — typically achieved with a digital signature or a message-authentication code. It is closely related to integrity (both detect tampering) but adds the who. The classical CIA triad omits it because authenticity and the related properties of non-repudiation and accountability were historically treated as distinct goals. Modern variants (CIANA, the Parkerian hexad) often add Authenticity (and sometimes Possession, Utility) explicitly — useful, but not what the standard CIA triad refers to.