COURSE 3: BACKEND DEVELOPMENT, DATABASES, AND MODERN SOFTWARE ENGINEERING

Stage 3 (Senior Stage 3) — Academic Study Notes

---

Welcome to Stage 3 Software Engineering

When you load your favorite social media feed, purchase a ticket online, or chat with a friend via an app, you are interacting with the "frontend"—the beautiful, responsive user interface. But beneath that visual surface lies an incredibly complex engine working silently in the background. This engine is the backend.

Backend development, database design, and modern software engineering practices are the scaffolding, pillars, and utility systems of the digital world. Without them, applications would be empty shells, unable to store information, authenticate users, or process payments.

This comprehensive study guide is designed to take you from a user of technology to an architect of technology. You will explore how data flows across the globe, how databases store and retrieve billions of records in milliseconds, and how engineering teams write, test, and deploy production-grade software.

---

Section 1: Comprehensive Core Concepts

Concept 1: The Client-Server Architecture & APIs

At the heart of the modern internet is the Client-Server Architecture. This model partitions tasks or workloads between service providers (servers) and service requesters (clients).

+------------------+                  Request (HTTP/HTTPS)                  +------------------+
|                  | -----------------------------------------------------> |                  |
|      CLIENT      |                                                        |      SERVER      |
|  (Browser, App)  | <----------------------------------------------------- |  (Backend App)   |
|                  |                  Response (HTML, JSON)                 |                  |
+------------------+                                                        +------------------+

The Client

The client is any device or application that requests information or services. This is typically a web browser (like Chrome, Safari, or Firefox), a mobile application, or even an IoT (Internet of Things) device like a smart thermostat. The client's job is to present data to the user and capture user inputs.

The Server

The server is a high-powered computer, virtual machine, or container running constantly in a data center or cloud environment. Its primary job is to listen for incoming requests from clients, process those requests (which might involve running calculations or checking a database), and send back an appropriate response.

The HTTP Protocol & Request-Response Cycle

Communication between client and server occurs via protocols, primarily HTTP (Hypertext Transfer Protocol) and its secure version, HTTPS. This communication relies on a strict request-response pattern:

1. The Request: The client sends an HTTP request containing a URL, a Method (specifying the action to take), Headers (metadata such as authentication tokens or content types), and an optional Body (the data being sent, such as a username and password).
2. The Response: The server processes the request and returns an HTTP response containing a Status Code (indicating success or failure), Headers (metadata about the response), and a Body (typically HTML, CSS, JavaScript, or raw data formatted as JSON).

Common HTTP Methods:

• GET: Retrieve data from the server (e.g., loading your profile page).
• POST: Send new data to the server to create a resource (e.g., signing up for a new account).
• PUT / PATCH: Update existing data on the server (e.g., editing a post).
• DELETE: Remove data from the server (e.g., deleting a photo).

Standard HTTP Status Codes:

• 200 OK: The request was successful, and the server returned the requested data.
• 201 Created: The request was successful, and a new resource was created.
• 400 Bad Request: The server could not understand the request due to invalid syntax from the client.
• 401 Unauthorized: The client must authenticate itself to get the requested response.
• 404 Not Found: The server cannot find the requested resource.
• 500 Internal Server Error: The server encountered a situation it does not know how to handle.

APIs (Application Programming Interfaces) & REST

An API is a set of rules and protocols that allows one software application to talk to another. In backend development, APIs act as the doorway to the server's capabilities.

The most common architectural style for web APIs is REST (Representational State Transfer). A RESTful API organizes resources (like users, products, or posts) into unique URLs (endpoints) and uses standard HTTP methods to interact with them.

REST Endpoint Example:

• GET /api/v1/students — Retrieves a list of all students.
• POST /api/v1/students — Adds a new student to the system.
• GET /api/v1/students/102 — Retrieves the details of the student with ID 102.

// Example of an API JSON Response for GET /api/v1/students/102
{
  "id": 102,
  "name": "Jane Doe",
  "grade": 12,
  "courses": ["Backend Development", "Physics", "Calculus"],
  "enrolled": true
}

---

Concept 2: Databases and Data Modeling

Applications are dynamic because they retain state. A social media app remembers your posts; an online store remembers items in your cart. This state is managed using Databases.

Figure 1: High-performance data centers house the physical servers and databases that store our global digital footprints.

Databases are generally categorized into two major paradigms: Relational (SQL) and Non-Relational (NoSQL).

Relational Databases (SQL)

Relational databases store data in structured, two-dimensional tables consisting of columns (attributes) and rows (records). These tables are connected to one another through defined mathematical relationships.

• Structured Query Language (SQL): The standardized programming language used to manage and manipulate relational databases.
• Primary Key (PK): A unique identifier for every record within a table (e.g., student_id).
• Foreign Key (FK): A field in one table that links to the Primary Key of another table, creating a relationship between them.

Database Normalization

To prevent redundancy and protect data integrity, database designers practice normalization. This is the process of structuring a database to reduce data duplication. For instance, rather than storing a student's address, class name, teacher's name, and grades all in one giant table, normalized design splits this data into separate tables (Students, Classes, Enrollments) and links them using foreign keys.

       STUDENTS TABLE                               ENROLLMENTS TABLE                             CLASSES TABLE
+----+------------+-------+                  +----+------------+----------+                +----+----------------+-----------+
| ID | Name       | Grade |                  | ID | Student_ID | Class_ID |                | ID | Course_Name    | Room      |
+----+------------+-------+                  +----+------------+----------+                +----+----------------+-----------+
| 1  | Jane Doe   | 12    | <---+            | 50 | 1          | 301      | +------------> |301 | Backend Dev    | Lab B     |
| 2  | John Smith | 11    |     +----------| 51 | 1          | 302      |                |302 | Advanced Chem  | Lab D     |
+----+------------+-------+                  +----+------------+----------+                +----+----------------+-----------+

Non-Relational Databases (NoSQL)

NoSQL (Not Only SQL) databases do not use tabular relations. Instead, they store data in formats optimized for specific requirements, such as high-velocity changes, horizontal scaling, or unstructured data.

• Document Databases (e.g., MongoDB): Store data in JSON-like structures called documents. This allows for hierarchical nesting of data (e.g., storing an address directly inside a user record instead of linking to another table).
• Key-Value Stores (e.g., Redis): Act like a giant dictionary, mapping unique keys to values. They are extremely fast and commonly used for caching temporary data.

---

Concept 3: Modern Software Engineering Practices

Writing functional code is only a small part of software engineering. Building complex systems that survive production workloads, multiple developers working concurrently, and constant updates requires rigorous engineering practices.

Figure 2: Writing and managing code using version control systems like Git forms the backbone of team-based software engineering.

1. Version Control Systems (VCS) with Git

When multiple engineers work on the same codebase, they use Git to track changes, coordinate development, and prevent code conflicts.

• Repository (Repo): The project folder containing all code files and the history of changes.
• Commit: A saved snapshot of changes made to the codebase, documented with a commit message.
• Branching: Creating an isolated copy of the main codebase (often called main or master) where a developer can build new features without breaking the live application.
• Merging & Pull Requests: The process of reviewing, testing, and combining code from a feature branch back into the main branch.

Main Branch:     (Commit A) --------------------------> (Commit C) -> Merged Feature
                               \                       /
Feature Branch:                 \--> (Commit B: Work) /

2. Software Testing Paradigms

To guarantee that modifications do not break existing features, engineers build automated test suites.

• Unit Tests: Test the smallest testable parts of an application (like a single function or method) in isolation.
• Integration Tests: Test how different components of an app work together (such as checking if the API can write successfully to the database).
• End-to-End (E2E) Tests: Simulate real user interactions on a fully deployed application, checking that everything from UI clicks to backend data storage operates correctly.

3. Continuous Integration and Continuous Deployment (CI/CD)

CI/CD is the pipeline through which code is automatically tested, built, and released.

• Continuous Integration (CI): Every time a developer pushes code changes to a Git repository, automated scripts run the test suite. If any test fails, the build breaks, notifying the developer immediately.
• Continuous Deployment (CD): If all tests pass, the code is automatically compiled, packaged, and shipped directly to the cloud servers hosting the live application. This enables organizations to update their software multiple times a day with high confidence.

---

Section 2: Real-World Examples & Scenarios

Understanding code structures is easier when you see how they scale to support everyday platforms.

Scenario A: What Happens When You "Like" a Post?

Think about tapping the heart icon on a social media app. This tiny action sets off a cascade of events across the client-server architecture:

[ Your Device (Client) ] 
       │ 
       ▼ (Sends HTTP POST /posts/98721/likes with Auth Token)
[ Backend Load Balancer ] 
       │ 
       ▼ (Routes request to an available server instance)
[ Express/Flask Server Application ]
       │
       ├──► [ Authentication Service ] (Validates token; confirms you are who you say you are)
       ├──► [ Database Service (Postgres) ] (Executes SQL: INSERT INTO likes (user_id, post_id)...)
       └──► [ Notification Service (Redis Queue) ] (Pushes alert: "User X liked your post" to the author)
       │
       ▼ (Returns HTTP 201 Created Status + updated like count)
[ Your Device (Client) ] (Animates the heart to pink/red and increments the counter instantly)

---

Scenario B: The E-Commerce Black Friday Rush

During a flash sale, thousands of shoppers try to buy the last remaining game console at the exact same millisecond.

                                      DATABASE TRANSACTION WALL
                                 +--------------------------------+
Shopper A (Clicks 'Buy') ------> | Read Stock: 1                  | ====> Trans. A Locks Row
                                 | Update Stock: 1 - 1 = 0 (Save) | ====> Trans. A Succeeds!
                                 +--------------------------------+
                                                 || (Locks Released)
                                                 ▼
                                 +--------------------------------+
Shopper B (Clicks 'Buy') ------> | Read Stock: 0                  | ====> Trans. B Blocked
                                 | Abort: Out of stock!           | ====> Trans. B Fails Safely
                                 +--------------------------------+

Relational databases use ACID Transactions to handle this concurrency cleanly:

• Atomicity: The entire purchase process (charging the card, updating inventory, creating the order invoice) must succeed together. If the card payment fails, the inventory update is automatically undone (rolled back).
• Consistency: The database cannot drop below 0 stock units.
• Isolation: Shopper A's transaction is processed independently of Shopper B's transaction to prevent race conditions.
• Durability: Once the purchase is completed, the receipt is permanently written to physical disk, surviving any sudden power loss or server crash.

---

Section 3: Practical Applications & Step-by-Step Guides

Let's build actual backend components! Follow these practical exercises to build a lightweight API server and design queries for a structured relational database.

Guide 1: Building a Web API with Python & Flask

We will build a simple API server that handles a collection of books.

Prerequisites:

1. Ensure Python 3 is installed on your computer.
2. Open your terminal or command prompt.
3. Install Flask by running:

   pip install Flask
   

Step-by-Step Code:

Create a file named app.py and write the following code:

from flask import Flask, jsonify, request

app = Flask(__name__)

# Our local temporary in-memory data store (Simulating a database)
books_db = [
    {"id": 1, "title": "To Kill a Mockingbird", "author": "Harper Lee"},
    {"id": 2, "title": "The Hobbit", "author": "J.R.R. Tolkien"}
]

# 1. Define a GET endpoint to retrieve all books
@app.route('/api/books', methods=['GET'])
def get_books():
    return jsonify({"books": books_db}), 200

# 2. Define a GET endpoint to retrieve a single book by ID
@app.route('/api/books/<int:book_id>', methods=['GET'])
def get_book_by_id(book_id):
    # Search for the book in our local list
    book = next((book for book in books_db if book["id"] == book_id), None)
    if book:
        return jsonify(book), 200
    else:
        return jsonify({"error": "Book not found"}), 404

# 3. Define a POST endpoint to add a new book
@app.route('/api/books', methods=['POST'])
def add_book():
    # Verify client sent valid JSON data
    if not request.json or 'title' not in request.json or 'author' not in request.json:
        return jsonify({"error": "Bad Request. Title and Author are required."}), 400
    
    new_book = {
        "id": books_db[-1]["id"] + 1 if books_db else 1,
        "title": request.json['title'],
        "author": request.json['author']
    }
    books_db.append(new_book)
    return jsonify(new_book), 201

if __name__ == '__main__':
    print("Starting Flask Web Server on http://127.0.0.1:5000")
    app.run(debug=True)

Running & Testing Your API:

1. Run your program in your terminal:

   python app.py
   

2. Open your web browser and navigate to: http://127.0.0.1:5000/api/books
   • Expected output: You should see the raw JSON array containing both books.
3. Test your error handling by navigating to: http://127.0.0.1:5000/api/books/99
   • Expected output: You will see {"error": "Book not found"} with a 404 status.

---

Guide 2: Structured Query Language (SQL) Foundations

Relational databases use standard SQL syntax to read and write records. Below is a structured script designed to build a virtual school directory.

-- 1. Create a table for Students
CREATE TABLE Students (
    student_id INTEGER PRIMARY KEY AUTOINCREMENT,
    first_name TEXT NOT NULL,
    last_name TEXT NOT NULL,
    grade_level INTEGER DEFAULT 12,
    email TEXT UNIQUE
);

-- 2. Create a table for Classes
CREATE TABLE Classes (
    class_id INTEGER PRIMARY KEY AUTOINCREMENT,
    class_name TEXT NOT NULL,
    room_number TEXT
);

-- 3. Create an association table for Enrollments (Many-to-Many Relationship)
CREATE TABLE Enrollments (
    enrollment_id INTEGER PRIMARY KEY AUTOINCREMENT,
    student_id INTEGER,
    class_id INTEGER,
    enrollment_date DATE DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY(student_id) REFERENCES Students(student_id),
    FOREIGN KEY(class_id) REFERENCES Classes(class_id)
);

-- 4. Seed Data (Insert entries into our tables)
INSERT INTO Students (first_name, last_name, grade_level, email) VALUES 
('Alex', 'Mercer', 12, '[email protected]'),
('Beatrice', 'Vance', 11, '[email protected]'),
('Charles', 'Xavier', 12, '[email protected]');

INSERT INTO Classes (class_name, room_number) VALUES 
('Advanced Software Engineering', 'Lab 304'),
('Computational Physics', 'Room 102');

-- Associate Alex (ID: 1) and Beatrice (ID: 2) with Advanced Software Engineering (ID: 1)
INSERT INTO Enrollments (student_id, class_id) VALUES 
(1, 1),
(2, 1);

-- 5. Querying Database with Inner Joins
-- This retrieves which students are taking which classes
SELECT 
    Students.first_name, 
    Students.last_name, 
    Classes.class_name, 
    Classes.room_number
FROM Enrollments
INNER JOIN Students ON Enrollments.student_id = Students.student_id
INNER JOIN Classes ON Enrollments.class_id = Classes.class_id;

-- Query Results Output:
+------------+-----------+-------------------------------+-------------+
| first_name | last_name | class_name                    | room_number |
+------------+-----------+-------------------------------+-------------+
| Alex       | Mercer    | Advanced Software Engineering | Lab 304     |
| Beatrice   | Vance     | Advanced Software Engineering | Lab 304     |
+------------+-----------+-------------------------------+-------------+

---

Section 4: Suggested Project-Based Learning (PBL)

Project: The Community Resource Exchange Engine (CREE)

Objective

Apply backend development, database management, and structured design principles to build a working backend engine for a neighborhood tool-sharing program. This project enables community members to loan and borrow tools (such as lawnmowers, drills, or ladders), reducing waste and building neighborhood self-reliance.

Figure 3: Keeping track of shared assets requires logical database structuring, matching unique items to borrowers.

---

Phase 1: Conceptual ERD (Entity-Relationship Diagram)

Before coding, map out your relational schema on paper. Use this blueprint:

+------------------+             +-------------------+             +------------------+
|      USERS       |             |   SHARED_ITEMS    |             |    BORROWS       |
+------------------+             +-------------------+             +------------------+
| PK: user_id      | 1--------+  | PK: item_id       | 1--------+  | PK: borrow_id    |
|     name         |          |  |     title         |          |  | FK: user_id      |
|     contact_info |          +->| FK: owner_id      |          +->| FK: item_id      |
+------------------+             |     status        |             |     return_date  |
                                 +-------------------+             +------------------+

---

Phase 2: Building the Scripted Engine

We will construct this system using Python's built-in SQLite database library.

Create a file named cree_engine.py and implement this script:

import sqlite3
import os

DB_FILE = "community_sharing.db"

def initialize_database():
    """Establishes connections and creates tables if they don't exist."""
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    
    # Enable foreign keys support in SQLite
    cursor.execute("PRAGMA foreign_keys = ON;")
    
    # Create Users table
    cursor.execute('''
        CREATE TABLE IF NOT EXISTS Users (
            user_id INTEGER PRIMARY KEY AUTOINCREMENT,
            name TEXT NOT NULL,
            phone TEXT NOT NULL UNIQUE
        )
    ''')
    
    # Create Items table
    cursor.execute('''
        CREATE TABLE IF NOT EXISTS Items (
            item_id INTEGER PRIMARY KEY AUTOINCREMENT,
            title TEXT NOT NULL,
            status TEXT NOT NULL CHECK(status IN ('Available', 'Borrowed')),
            owner_id INTEGER,
            FOREIGN KEY(owner_id) REFERENCES Users(user_id)
        )
    ''')
    
    # Create Borrows table
    cursor.execute('''
        CREATE TABLE IF NOT EXISTS Borrows (
            borrow_id INTEGER PRIMARY KEY AUTOINCREMENT,
            user_id INTEGER,
            item_id INTEGER,
            checkout_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
            FOREIGN KEY(user_id) REFERENCES Users(user_id),
            FOREIGN KEY(item_id) REFERENCES Items(item_id)
        )
    ''')
    
    conn.commit()
    conn.close()
    print("[CREE Engine] System database tables initialized successfully.")

def register_user(name, phone):
    """Inserts a new user into the database."""
    try:
        conn = sqlite3.connect(DB_FILE)
        cursor = conn.cursor()
        cursor.execute("INSERT INTO Users (name, phone) VALUES (?, ?)", (name, phone))
        conn.commit()
        print(f"[Success] Registered user: {name}")
    except sqlite3.IntegrityError:
        print(f"[Error] Phone registration conflict. {phone} already exists.")
    finally:
        conn.close()

def list_item_for_sharing(title, owner_id):
    """Registers a shared item owned by a user."""
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    cursor.execute("INSERT INTO Items (title, status, owner_id) VALUES (?, 'Available', ?)", (title, owner_id))
    conn.commit()
    conn.close()
    print(f"[Success] Listed '{title}' for community exchange.")

def borrow_item(borrower_id, item_id):
    """Executes transaction checking out an item to a borrower."""
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    
    # Check if item is available
    cursor.execute("SELECT status, title FROM Items WHERE item_id = ?", (item_id,))
    result = cursor.fetchone()
    
    if not result:
        print("[Error] Item not found.")
        conn.close()
        return
    
    status, title = result[0], result[1]
    if status == 'Borrowed':
        print(f"[Unavailable] '{title}' is checked out by another neighbor.")
        conn.close()
        return
    
    # Execute atomic checkout actions
    try:
        # Mark item status as Borrowed
        cursor.execute("UPDATE Items SET status = 'Borrowed' WHERE item_id = ?", (item_id,))
        # Register Transaction log
        cursor.execute("INSERT INTO Borrows (user_id, item_id) VALUES (?, ?)", (borrower_id, item_id))
        conn.commit()
        print(f"[Transaction Executed] Item '{title}' has been issued successfully.")
    except Exception as e:
        conn.rollback()
        print(f"[Failure] Checkout aborted: {e}")
    finally:
        conn.close()

# Main Driver Script
if __name__ == "__main__":
    # Clean up previous run files if testing fresh
    if os.path.exists(DB_FILE):
        os.remove(DB_FILE)
        
    initialize_database()
    
    # 1. Add Community Members
    register_user("Alice Green", "555-0199")
    register_user("Bob Stone", "555-0144")
    
    # 2. Add community inventory
    # Alice (User ID: 1) lists a Chainsaw
    list_item_for_sharing("Hedge Trimmer", 1)
    # Bob (User ID: 2) lists a Ladder
    list_item_for_sharing("Extension Ladder", 2)
    
    # 3. Simulate Bob trying to borrow Alice's trimmer (Item ID: 1)
    print("\n--- Transaction Phase 1 ---")
    borrow_item(2, 1) # Expected: Success
    
    # 4. Simulate a third party attempting to borrow the same item
    print("\n--- Transaction Phase 2 ---")
    borrow_item(1, 1) # Expected: Blocked (Already Borrowed)

---

Section 5: Home Practice Activities

Activity 1: Normalization Pen-and-Paper Challenge

You are handed a spreadsheet tracking a library book club. It is completely unnormalized:

Task:

Normalize this spreadsheet into Third Normal Form (3NF).

1. Write down the names of the three separate tables you should create.
2. Define the Columns (Attributes), Primary Keys, and Foreign Keys required to link them together without duplicating Dave's metadata every time he borrows a new book.

Expected Outcome:

Students should sketch a layout on paper showing:

• Members table (contains Member_ID, Name, Genre).
• Books table (contains Book_ID, Title).
• Loans table (contains Loan_ID, Member_ID, Book_ID, Due_Date).

---

Activity 2: Local Version Control Lab

Practice basic version control commands locally. Open a terminal on your computer and run the following sequence:

# 1. Initialize git in an empty practice directory
mkdir git_challenge
cd git_challenge
git init

# 2. Configure identity (if not already done)
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# 3. Create a clean file
echo "print('Version 1.0')" > script.py

# 4. Save/Commit this snapshot
git add script.py
git commit -m "Initial release of script"

# 5. Create a new branch for experimental features
git checkout -b experimental_features

# 6. Make a change in the new branch
echo "print('Version 2.0-Alpha')" > script.py
git add script.py
git commit -m "Upgraded to 2.0-Alpha on branch"

# 7. Merge changes back
git checkout main
git merge experimental_features

Verify the result: Run cat script.py (Mac/Linux) or type script.py (Windows) to confirm your script has successfully merged into version 2.0-Alpha.

---

Section 6: Life Skills & Career Integration

The principles of backend systems and software engineering extend far beyond screen-based environments. They help you build cognitive workflows that are useful in many different career paths.

       SOFTWARE PRINCIPLE                          REAL-WORLD LIFE APPLICATION
+------------------------------+                +-------------------------------+
|      Version Control         |                |   Iterative Document Editing  |
| (Checkpoints & Rollbacks)    | -------------> | (Never save over good ideas;  |
|                              |                | keep structured change logs)  |
+------------------------------+                +-------------------------------+
                                                                │
                                                                ▼
+------------------------------+                +-------------------------------+
|     Database Schema          |                |      Organizing Workspaces     |
| (One central source of truth)| -------------> | (Store keys, tools, records   |
|                              |                | in precise, indexed zones)    |
+------------------------------+                +-------------------------------+
                                                                │
                                                                ▼
+------------------------------+                +-------------------------------+
|       API Integration        |                |  Clear Personal Delegation    |
| (Contract-based communication| -------------> | (Establishing firm rules for  |
|      prevents errors)        |                | inputs and output expectations|
+------------------------------+                +-------------------------------+

Systems Thinking as a Cognitive Tool

Designing complex databases forces you to develop a mindset of Systems Thinking. When you look at an organization (like a school, hospital, or logistics company), you no longer see a chaotic mass of tasks. Instead, you see structured entities, relations, data flows, and constraints. This clarity allows you to isolate problems quickly—whether you are debugging a faulty API endpoint, resolving a bottleneck in an online order fulfillment line, or structuring a team workspace.

Career Pathways

• Database Administrator (DBA): The guardian of an organization's records. They specialize in speed optimizations, index design, backup restoration, security permissions, and maintaining system availability.
• DevOps Engineer: The bridge between developers and operations teams. They write the automated pipelines (CI/CD) and configure the server environments in the cloud where software runs.
• Backend Developer: Architects of logical APIs and background systems. They write business logic in languages like Python, Go, Node.js, and Java, making sure clients receive accurate, secure data fast.

---

Section 7: Assessment Through Application

Verify your understanding of these concepts by completing one of the options below.

Option A: Complete Database Redesign Pitch

Look at your school's daily operational flow (managing homework, attendance, library books, and club schedules).

1. Identify three major data tables needed to support an integrated student app.
2. Outline the Primary Keys and Foreign Keys that link these tables together.
3. Draw an Entity-Relationship Diagram (ERD) mapping these interactions.
4. Write out three distinct SQL commands that would allow a teacher to query this database (e.g., retrieving a list of all students who missed attendance, sorted by grade level).

Option B: The "API Endpoint" Security Audit

Study the JSON transaction script shown below:

POST /api/v1/update-balance HTTP/1.1
Host: communitybank.com
Content-Type: application/json

{
  "user_account_id": "9918231",
  "add_balance": 5000.00
}

Write a brief 1–2 page security assessment identifying the vulnerabilities in this setup. Focus on:

• Why using POST with a client-provided account number and value is dangerous without authorization validation.
• How an attacker could modify the payload to exploit this endpoint.
• What specific security controls (such as token validation, transaction signatures, and server-side balance verifications) should be added to prevent fraudulent transactions.

---

Section 8: Student Reflection Questions

Take a moment to reflect on these structural principles. These questions can help you think deeper about the concepts:

1. The Principle of Trust: Why should a backend server never trust input sent directly from a client browser? What kinds of validation must occur inside the server app before updating a database?
2. The Impermanence of Speed: We saw that NoSQL key-value stores like Redis are incredibly fast because they run in memory (RAM). However, when a power loss occurs, RAM loses its state, unlike databases stored on physical SSDs. How can engineers balance speed and data durability in modern, high-traffic applications?
3. The Philosophy of Automation: In CI/CD pipelines, we automate tests to remove human error from deployments. Is there any danger in trusting automated systems to push code straight to live production? What guardrails would you build into a team's workflow to manage this risk safely?