Introduction to System Design and Architecture

Welcome to System Design

This is the first lesson in our course, so we will set the foundation before diving into specific topics like high-level design, low-level design, microservices, databases, cloud architecture, design patterns, and a full e-commerce project.

As a Java and Spring Boot developer, you already know how to write services and APIs. System design asks a bigger question:

How should all the pieces work together so the application is useful, reliable, scalable, and maintainable?

Think of this course as moving from writing code to designing systems that code can live inside.

By the end of this lesson, you should be able to explain:

• What a software system is
• What architecture means
• Why design decisions involve tradeoffs
• How requirements shape technical choices
• How to start thinking like a system designer

What Is System Design?

A system is a group of parts that work together to achieve a goal.

A food delivery app, for example, is not just one screen or one API. It includes:

• A customer app
• A restaurant dashboard
• A delivery partner app
• Backend APIs
• Databases
• Payment processing
• Notifications
• Monitoring and support tools

System design is the process of deciding how these parts should be organized and how they should communicate.

A simple request might look like this:

User clicks "Place Order"
        |
        v
Backend API validates order
        |
        v
Database stores order
        |
        v
Payment provider charges user
        |
        v
Notification service sends update

The code matters, but so does the arrangement of the code, data, network calls, failure handling, and operational behavior.

Architecture vs Design

People often use architecture and design interchangeably, but they are not exactly the same.

Idea Focus Example Question Architecture Big structural decisions Should this be a monolith or microservices? High-level design Major components and interactions What services, databases, queues, and external systems are needed? Low-level design Internal implementation details What classes, interfaces, methods, and data models should we create?

A useful analogy:

• Architecture is the city plan: roads, zones, power, water, hospitals.
• High-level design is the building plan: floors, rooms, elevators, entrances.
• Low-level design is the room detail: wiring, switches, furniture placement.

In later lessons, we will go deeper into high-level and low-level design separately. For now, remember that architecture gives the system its overall shape.

A Tiny System in Java

Before we discuss cloud diagrams or distributed systems, let's model a very small system in plain Java.

The goal is not to build a real e-commerce platform yet. The goal is to notice that even a tiny order flow has multiple responsibilities:

• Taking an order
• Checking inventory
• Saving or confirming the order
• Notifying the customer

In real applications, these might become classes, Spring services, REST APIs, database tables, queues, or separate microservices. But the core design thinking starts here: separate responsibilities clearly.

```java
class Main {
    public static void main(String[] args) {
        InventoryService inventory = new InventoryService();
        NotificationService notifications = new NotificationService();
        OrderService orders = new OrderService(inventory, notifications);

        orders.placeOrder("ORD-1001", "Laptop", 1);
    }
}

class OrderService {
    private final InventoryService inventoryService;
    private final NotificationService notificationService;

    OrderService(InventoryService inventoryService, NotificationService notificationService) {
        this.inventoryService = inventoryService;
        this.notificationService = notificationService;
    }

    void placeOrder(String orderId, String item, int quantity) {
        System.out.println("Received order: " + orderId);

        if (inventoryService.isAvailable(item, quantity)) {
            System.out.println("Order confirmed for item: " + item);
            notificationService.send("Your order " + orderId + " is confirmed.");
        } else {
            System.out.println("Order rejected: item unavailable");
            notificationService.send("Your order " + orderId + " could not be completed.");
        }
    }
}

class InventoryService {
    boolean isAvailable(String item, int quantity) {
        System.out.println("Checking inventory for " + quantity + " x " + item);
        return quantity <= 5;
    }
}

class NotificationService {
    void send(String message) {
        System.out.println("Notification sent: " + message);
    }
}
```

Which statement best describes system design?

Requirements Drive Architecture

A common beginner mistake is to start with a favorite technology: "Let's use Kafka," "Let's use microservices," or "Let's put everything on Kubernetes."

Good system design starts with requirements.

Functional requirements

These describe what the system should do.

For an online store:

• Users can browse products
• Users can add items to a cart
• Users can place orders
• Admins can update inventory

Non-functional requirements

These describe how well the system should behave.

Examples:

• Scalability: Can it handle more users?
• Availability: Does it stay online during failures?
• Latency: Does it respond quickly?
• Security: Does it protect sensitive data?
• Maintainability: Can developers safely change it later?

Most architecture decisions are attempts to satisfy these requirements under real-world constraints like time, cost, team size, and complexity.

Scalability, availability, latency, security, and maintainability are examples of __________ requirements.

A Practical Design Loop

System design is not magic. It is a repeatable thinking process.

A useful loop is:

1. Understand the goal
2. Clarify requirements
3. Identify constraints
4. Choose components
5. Define interactions
6. Evaluate tradeoffs
7. Iterate

For example, suppose we are building a simple URL shortener.

Before choosing code structure, we should ask:

• How many links will be created per day?
• How many redirects will happen per second?
• Should links expire?
• Do we need analytics?
• What happens if the database is temporarily slow?

The answers change the design. A personal hobby app and a global service used by millions should not have the same architecture.

True or false: A good system design always maximizes scalability, security, performance, simplicity, and cost savings at the same time.

Seeing a Tradeoff

Let's use a tiny Java simulation to make one design tradeoff visible.

Imagine a service that needs product details. It can either:

• Read from a slower database every time
• Use a faster cache after the first read

Caching can reduce latency, but it also adds complexity: invalidation, stale data, memory usage, and extra operational concerns.

This example is intentionally small, but the lesson is big:

Architecture decisions are rarely "free." They improve something by accepting a cost somewhere else.

```java
import java.util.HashMap;
import java.util.Map;

class Main {
    public static void main(String[] args) {
        ProductCatalog catalog = new ProductCatalog();

        catalog.getProduct("P-100");
        catalog.getProduct("P-100");
        catalog.getProduct("P-200");
        catalog.getProduct("P-100");
    }
}

class ProductCatalog {
    private final Map<String, String> cache = new HashMap<>();

    String getProduct(String productId) {
        if (cache.containsKey(productId)) {
            System.out.println("CACHE HIT  for " + productId + " -> fast response");
            return cache.get(productId);
        }

        System.out.println("CACHE MISS for " + productId + " -> reading from database");
        String product = readFromDatabase(productId);
        cache.put(productId, product);
        return product;
    }

    private String readFromDatabase(String productId) {
        return "Product details for " + productId;
    }
}
```