SOFTWARE ARCHITECTURE

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage to move in the opposite direction"
Designing software architecture is about arranging components of a system to best fit the desired quality attributes of the system.

The user cares that your system is fast, reliable, and available
The project manager cares that the system is delivered on time and on budget
The CEO cares that the system contributes incremental value to his/her company
The head of security cares that the system is protected from malicious attacks
The application support team cares that the system is easy to understand and debug

There is no way to please everyone without sacrificing the quality of the system. Therefore, when designing software architecture, you must decide which quality attributes matter most for the given business problem. Below are a few examples of quality attributes:

Performance: how long do you have to wait before that spinning "loading" icon goes away?
Availability: what percentage of the time is the system running?
Usability: can the users easily figure out the interface of the system?
Modifiability: if the developers want to add a feature to the system, is it easy to do?
Interoperability: does the system play nicely with other systems?
Security: does the system have a secure fortress around it?
Portability: can the system run on many different platforms (i.e. Windows vs. Mac vs. Linux)?
Scalability: if you grow your userbase rapidly, can the system easily scale to meet the new traffic?
Deployability: is it easy to put a new feature in production?
Safety: if the software controls physical things, is it a hazard to real people?

Depending on what software you are building or improving, certain attributes may be more critical to success. If you are a financial services company, the most important quality attribute for your system would probably be security (a breach of security could cause your clients to lose millions of dollars) followed by availability (your clients need to always have access to their assets). If you are a gaming or video streaming company (i.e. Netflix), your first quality attribute is going to be performance because if your games/movies freeze up all the time, nobody will play/watch them.

The process of building software architecture is not about finding the best tools and the latest technologies. It's about delivering a system that works effectively.

Basic Design Principles

SOLID Principles
The SOLID principles are five fundamental design principles that help developers create more maintainable, flexible, and scalable software. Let's explore each one:
- Single Responsibility Principle (SRP)
  This principle states that a class should have only one reason to change, meaning it should have only one responsibility or job. When a class handles multiple responsibilities, it becomes coupled in multiple ways, making it more fragile and difficult to maintain.
  Example:
  Instead of having a User class that handles user authentication, profile management, and notification sending, break it into separate classes:
  - UserAuthentication for login/logout functionality
  - UserProfileManager for profile updates
  - UserNotifier for sending notifications
  This separation makes each class simpler, more focused, and easier to modify without affecting other parts of the system.
- Open/Closed Principle (OCP)
  Software entities (classes, modules, functions) should be open for extension but closed for modification. This means you should be able to add new functionality without changing existing code.
  Example:
  Instead of having a PaymentProcessor class with if-else statements for different payment methods that requires modification each time a new payment method is added:
```
 class PaymentProcessor:
   def process_payment(self, payment_type):
      if payment_type == "CreditCard":
        self.process_credit_card()
      elif payment_type == "PayPal":
        self.process_paypal()  # Adding a new method requires modifying this class
```
  Better Approach (OCP Applied):
```
from abc import ABC, abstractmethod

class PaymentMethod(ABC):
   @abstractmethod
   def process(self):
       pass

class CreditCardPayment(PaymentMethod):
   def process(self):
       pass

class PayPalPayment(PaymentMethod):
   def process(self):
       pass
```
- Liskov Substitution Principle (LSP)
  Subtypes must be substitutable for their base types without altering the correctness of the program. In other words, if S is a subtype of T, objects of type T may be replaced with objects of type S without breaking the program.
  Example (Violation):
```
class Bird:
   def fly(self):
       pass

class Ostrich(Bird):
   def fly(self):  # Ostriches cannot fly, breaking the expectation
       raise NotImplementedError
```
  Better Approach (LSP Applied):
```
class Bird:
  pass

class FlyingBird(Bird):
  def fly(self):
    pass

class Ostrich(Bird):  # No need to implement fly()
  pass
```
- Interface Segregation Principle (ISP)
  No client should be forced to depend on methods it does not use. This principle suggests creating fine-grained interfaces that are client-specific rather than having one large, general-purpose interface.
  
  Example (Violation):
```
class Worker:
  def work(self):
     pass

  def eat(self):  # Not all workers eat (e.g., robots)
    pass
```
  Better Approach (ISP Applied):
```
class Workable:
  def work(self):
    pass

class Eatable:
  def eat(self):
    pass

class HumanWorker(Workable, Eatable):
   pass

class RobotWorker(Workable):  # Does not need to implement eat()
  pass
```
- Dependency Inversion Principle (DIP)
  High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This Reduces coupling, making the system flexible.
  Example (Violation):
```
class MySQLDatabase:
  def connect(self):
    pass

class DataManager:
  def __init__(self):
    self.db = MySQLDatabase()  # Tightly coupled to MySQL
```
  Better Approach (DIP Applied):
```
from abc import ABC, abstractmethod

class Database(ABC):
  @abstractmethod
  def connect(self):
    pass

class MySQLDatabase(Database):
  def connect(self):
    pass

class PostgreSQLDatabase(Database):
  def connect(self):
    pass

class DataManager:
  def __init__(self, db: Database):
    self.db = db  # Now any database can be used
```
DRY (Don't Repeat Yourself)
The DRY principle states that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." In simpler terms, avoid duplicating code, logic, or data.
Benefits:
- Reduces maintenance overhead
- Decreases the chances of bugs
- Makes the codebase more concise and easier to understand
- Facilitates changes that need to be applied consistently
Example (Violation):
```
def get_employee_salary(emp_id):
  # SQL query to get salary
  pass

def get_manager_salary(emp_id):
  # Almost same SQL query but duplicated logic
  pass
```
Better Approach (DRY Applied):
```
def get_salary(emp_id, role):
  # SQL query handling both employee and manager
  pass
```
KISS (Keep It Simple, Stupid)
The KISS principle advocates for simplicity in design and implementation. It suggests that most systems work best when they are kept simple rather than made complex.
Guidelines:
- Avoid over-engineering
- Start with the simplest solution that could possibly work
- Add complexity only when necessary
- Prefer readable, straightforward code over clever, complex solutions
Example (Violation):
```
class UserManager:
  def __init__(self, user_repo, email_service, logger, cache, metrics, 
  backup_service):
      pass  # Too many dependencies
```
Better Approach (KISS Applied):
```
class UserManager:
  def __init__(self, user_repo):
      self.user_repo = user_repo
```
YAGNI (You Aren’t Gonna Need It)
YAGNI is a principle from Extreme Programming that states you should not add functionality until it is necessary. It's about avoiding speculative development.

Benefits:
- Reduces code complexity
- Minimizes wasted effort
- Keeps the codebase focused on real, current requirements
- Prevents feature creep
Example: When building a user registration system, you might be tempted to include advanced features like:
- Social media integration
- Multi-factor authentication
- Different user roles and permissions
- Password reset via SMS
But if the current requirements don't call for these features, following YAGNI means you would implement just the basic registration functionality and add these other features only when they become necessary.
- Separation of Concerns (SoC)
  Separation of Concerns means dividing a software system into distinct features that overlap as little as possible. Each part of the system addresses a specific concern or aspect of functionality.
  
  Benefits:
  - Modularity: Each module can be developed, tested, and maintained independently.
  - Reusability: Individual components can be reused in different parts of the system or even in other projects.
  - Maintainability: Changes in one area (like the UI) do not ripple through unrelated areas (like business logic).
  Example:
  Consider a web application where:
  - The UI layer handles presentation.
  - The Business Logic layer manages rules and workflows.
  - The Data Access layer deals with data storage and retrieval.
  Each layer focuses on a specific concern, reducing coupling and enhancing flexibility.
- The Dependency Rule
  Often highlighted in Clean Architecture, the Dependency Rule states that source code dependencies should always point inward—from lower-level details to higher-level policies. In other words, high-level modules should not depend on low-level modules; both should depend on abstractions.
  Key Aspects:
  - Direction of Dependency: All dependencies should point toward the core business rules or the most abstract part of the system.
  - Abstraction Over Details: High-level components define interfaces, and low-level components implement them.
  - Flexibility: This rule enables the system to change low-level details (like switching a database) without impacting higher-level policies.
  Example, In a payment system:
  - Core Business Logic defines an interface for payment processing.
  - Implementations for credit card and PayPal payments adhere to that interface.
  The business logic remains unchanged even if the payment method changes, thanks to the inward-pointing dependency.
- Load Balancer
  A load balancer is a network component (or service) that distributes incoming network or application traffic across multiple servers. It ensures that no single server becomes a bottleneck, enhancing overall system performance and reliability.
  
  Benefits:
  - Scalability: Helps distribute the workload evenly as demand increases.
  - Fault Tolerance: If one server fails, traffic can be redirected to healthy servers.
  - Improved User Experience: Reduces latency by ensuring that no single server is overwhelmed.
  Design Considerations:
  - Algorithms: Round-robin, least connections, or IP-hash based distribution.
  - Session Persistence: Sometimes called “sticky sessions,” ensuring that a user’s requests are consistently sent to the same server.
  - Health Checks: Regular monitoring of backend servers to ensure they are functioning properly.
- Monolithic First Strategy
  A Monolithic First Strategy suggests that you start your application as a single, unified codebase (a monolith) rather than immediately breaking it into microservices or other distributed systems.
  
  Benefits:
  - Simplicity: Easier to develop, deploy, and test when all components reside within a single application.
  - Lower Overhead: Avoids the complexity of managing multiple services, which is especially beneficial in the early stages of development.
  - Faster Iteration: Teams can build and iterate quickly without worrying about network latency or inter-service communication issues.
  When to Evolve:
  Once the monolithic application scales to a point where different parts of the system have divergent requirements, or when the complexity of the monolith becomes a hindrance, it may then be refactored into microservices or another distributed architecture.
- Separated UI A Separated UI refers to the architectural pattern where the user interface (front end) is developed and deployed independently from the backend (application logic and data access).
Benefits:
- Independent Development: Frontend and backend teams can work concurrently using different technologies suited to their domain (e.g., React for the UI and Node.js for the backend).
- Scalability: Each layer can be scaled independently according to its needs.
- Flexibility in Deployment: Allows for modern practices such as single-page applications (SPAs) or progressive web apps (PWAs).
Implementation Approaches:
- API-Driven: The backend exposes RESTful or GraphQL APIs that the UI consumes.
- Micro Frontends: In larger applications, even the UI can be split into multiple smaller, independently deployable pieces.

Software Architecture

Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. It serves as the blueprint for both the system and the project developing it, defining:

Structure: The organization of components, modules, or services
Behavior: How these components interact and communicate
Properties: Non-functional requirements like performance, security, and scalability
Design decisions: The rationale behind key technical choices
Constraints: Limitations that affect the design (technical, business, regulatory)

Responsibilities:

Component Organization: Deciding how to divide the system into modules or services.
Communication: Establishing interaction protocols between components.
Scalability and Maintainability: Setting up the system to accommodate growth and change without significant rework.

Example:
Consider a typical e-commerce platform where the architecture defines separate components for:

user management,
inventory,
payment processing
order management.

These components communicate over well-defined APIs, ensuring that changes in one module (like updating the payment gateway) don’t adversely affect the others.

Architecture vs. Design

While the terms are often used interchangeably, they represent different levels of decision-making:

Software Architecture:
- Focus: High-level structure and overall organization.
- Scope: Decisions that affect the entire system, such as component boundaries, data flow, and technology choices.
Example:
Choosing a microservices architecture over a monolithic one, which influences deployment, scaling, and maintenance strategies.
Software Design:
- Focus: Implementation details within the architectural boundaries.
- Scope: Decisions about algorithms, data structures, and patterns within individual components.
Example:
Designing the specific classes for a payment processing module using patterns like Strategy or Observer.

Architecture is about making big-picture decisions that shape the system's foundation, while design is concerned with the finer details that make up each part of that foundation.
Think of architecture as the city planning (major roads, zoning) and design as the building plans (house layouts, plumbing details).

Architectural Qualities and Concerns

Architecture addresses both functional requirements (what the system should do) and quality attributes (how well it should do it).
Software architecture isn’t just about splitting the system into components; it also addresses several non-functional aspects—qualities that impact the overall behavior and performance of the system. Here are some key qualities:

Performance:
- Response time, throughput, resource utilization. How fast and efficiently the system responds under various conditions.
- Techniques: Caching, load balancing, asynchronous processing
Scalability
- Ability to handle growth in users, data, or transactions
- Horizontal scaling (more machines) vs. vertical scaling (more powerful machines)
Reliability
- System's ability to perform without failure
- Fault tolerance, error handling, recovery mechanisms
Availability
- Proportion of time the system is functional and working
- Redundancy, failover mechanisms, monitoring
Security
- Protection against unauthorized access and attacks
- Authentication, authorization, encryption, input validation
Maintainability
- Ease of making changes(modifications) and updates
- Modularity, separation of concerns, documentation
Usability
- How effectively users can use the system
- UI/UX considerations that impact architecture
Testability
- Ease of testing the system at various levels
- Dependency injection, separation of concerns, test harnesses

Basic Architectural Styles

There are several architectural styles, each with its own set of principles and trade-offs. Here are a few common ones:

Layered (N-tier) Architecture:
- Concept: Dividing the system into layers (presentation, business logic, data access) where each layer has a specific responsibility.
- Example: Traditional web applications where the user interface, business logic, and database access are separated into distinct layers.
- Benefits: Enhances maintainability and separation of concerns.
Monolithic Architecture:
- Concept: The entire system is built as a single unified codebase.
- Example: Early-stage applications where all functionalities (UI, business logic, data access) reside in one codebase.
- Benefits: Simplicity in development and deployment; easier testing initially.
- Drawbacks: Can become unwieldy(unmanageable) and difficult to scale as the system grows.
Microservices Architecture:
- Concept: Breaking the system into small, independent services that communicate over a network.
- Example: Modern e-commerce platforms where each service (user management, payment processing, inventory) operates as an independent microservice. Netflix, Amazon, Uber
- Benefits: Scalability, flexibility, Independent deployability, technology diversity and resilience; teams can work on different services concurrently.
- Drawbacks: Increased complexity in deployment, communication, and management.
Event-Driven Architecture:
- Concept: Components communicate by emitting and reacting to events.
- Example: Systems using message queues or event streams (like Kafka) where components react to events, such as user actions or data changes. trading platforms
- Benefits: Decouples components, making the system more resilient and scalable.
- Drawbacks: Can be complex to manage state and ensure consistency.
Service-Oriented Architecture (SOA):
- Concept: Similar to microservices, SOA focuses on services as discrete units that expose business functionalities via well-defined interfaces.
- Example: Enterprise systems integrating various services across different departments.
- Benefits: Reusability and integration of services across diverse platforms.
- Drawbacks: Often involves heavier protocols and can be more complex to implement than microservices.

Each architectural style has its own strengths and weaknesses, making them suitable for different types of applications and requirements. In practice, many systems use a combination of these styles, creating hybrid architectures that leverage the benefits of multiple approaches.

Design Patterns

Design patterns are proven solutions to common problems that occur during software development. They provide a shared vocabulary for developers and a blueprint for solving recurring design issues. By understanding these patterns, you can build systems that are more modular, scalable, and maintainable. Let’s dive into the details of design patterns, categorizing them into three main groups: Creational, Structural, and Behavioral patterns, and explore examples for each.

Creational Patterns
These patterns deal with object creation mechanisms, trying to create objects in a manner that is suitable to the situation. They abstract the instantiation process and help make a system independent of how its objects are created, composed, and represented.

Singleton:

Purpose: Ensure a class has only one instance and provide a global access point to it.

Example: A configuration manager that reads settings from a file should be a singleton to ensure consistency.

class SingletonMeta(type):
    _instance = None

    def __call__(cls, *args, **kwargs):
        if cls._instance is None:
            cls._instance = super().__call__(*args, **kwargs)
        return cls._instance

class ConfigManager(metaclass=SingletonMeta):
    def __init__(self):
        self.settings = self.load_settings()

    def load_settings(self):
        return {"env": "production", "debug": False}

config1 = ConfigManager()
config2 = ConfigManager()
print(config1 is config2)  # Output: True

Monolithic Architecture:

Monolithic architecture is a traditional software development approach where an entire application is built as a single, unified unit. All components of the application, such as the UI, business logic, and database access, are tightly integrated into a single codebase and deployed together.

Key Characteristics:

Single codebase for the entire application.
One executable or deployable unit.
All components (UI, business logic, and database) are tightly coupled.
Typically structured using layers (e.g., presentation, business logic, data access).
Centralized database.

Example of a Monolithic Architecture
Imagine a simple E-commerce Application that consists of the following components:

User Interface (UI): Handles user interactions.
Business Logic: Implements rules like order validation and payment processing.
Database Access Layer: Handles reading/writing data to a database.

In a monolithic architecture, all these components reside in a single codebase and are deployed as one unit.

# models.py
from django.db import models

class Product(models.Model):
    name = models.CharField(max_length=255)
    price = models.DecimalField(max_digits=10, decimal_places=2)
    stock = models.IntegerField()

class Order(models.Model):
    product = models.ForeignKey(Product, on_delete=models.CASCADE)
    quantity = models.IntegerField()
    total_price = models.DecimalField(max_digits=10, decimal_places=2)

# views.py
from django.shortcuts import render
from .models import Product, Order

def product_list(request):
    products = Product.objects.all()
    return render(request, 'products.html', {'products': products})

def place_order(request, product_id):
    product = Product.objects.get(id=product_id)
    order = Order.objects.create(product=product, quantity=1, total_price=product.price)
    return render(request, 'order_success.html', {'order': order})

+----------------------------------------------------+
|              Monolithic Application               |
| +----------------------------------------------+  |
| |  Presentation Layer (UI)                     |  |
| |  - HTML, CSS, JavaScript                     |  |
| |  - Templates (Django, Flask, Spring MVC)     |  |
| +----------------------------------------------+  |
| |  Business Logic Layer                        |  |
| |  - Order Processing, Payment Logic          |  |
| |  - Validation Rules                          |  |
| +----------------------------------------------+  |
| |  Data Access Layer                           |  |
| |  - ORM (Django ORM, Hibernate, SQLAlchemy)  |  |
| |  - SQL Queries                              |  |
| +----------------------------------------------+  |
| |  Database                                    |  |
| |  - PostgreSQL, MySQL                         |  |
+----------------------------------------------------+

Advantages of Monolithic Architecture
Despite the rise of microservices, monolithic architecture is still widely used because of its simplicity and efficiency.

Easy to Develop & Maintain (for Small Applications)
- A single codebase simplifies development.
- Easier debugging and testing since everything runs in one place.
Performance Benefits
- No inter-service communication overhead.
- Direct function calls are faster than API-based communication in microservices.
Simple Deployment
- One single application to deploy (e.g., one JAR file in Java, one Docker container).
- No complex service orchestration.
Simpler Data Management
- A single database makes queries and transactions straightforward.
Established Tools & Frameworks
- Frameworks like Django, Spring Boot, Laravel are optimized for monolithic applications.

Challenges of Monolithic Architecture
While monolithic applications work well for small projects, they introduce scalability and maintainability challenges as the system grows.

Scalability Issues
Monolithic applications are hard to scale horizontally (e.g., running multiple instances of only one module like "Orders" is impossible).
To scale one component, you must scale the entire application.
Large Codebase Complexity
As applications grow, the codebase becomes harder to manage.
New developers may struggle to understand dependencies between components.
Slow Development & Deployment A small change (e.g., modifying a single function) requires redeploying the entire application.
Large builds and tests slow down development cycles.
Technology Lock-in
Since everything is tightly coupled, migrating to a new technology (e.g., switching from Django to FastAPI) is difficult.
Fault Tolerance Issues
A single bug in one module can bring down the entire application.
If one component (e.g., payments) fails, the entire system may stop working.

When to Use Monolithic Architecture
Despite its drawbacks, monolithic architecture is still relevant in many scenarios.

✅ Best for:

Small to Medium Applications: Ideal for startups and simple projects.
Rapid Development: If you need to build and launch quickly.
Single Team Development: When a small team is working on the project.
Limited Budget: Monoliths are easier and cheaper to deploy and maintain.

❌ Avoid Monolithic Architecture If:

The application is expected to scale rapidly.
There are multiple teams working on different modules.
You need independent deployment for different services.

Many companies start with a monolithic architecture and later transition to microservices as they scale.
A typical strategy is:

Identify Independent Modules (e.g., Orders, Payments).
Extract Each Module into a Separate Service.
Implement API Communication Between Services.
Migrate to a Distributed Database Approach.

Example E-commerce System Split into Microservices:

Monolithic: Everything (Products, Orders, Payments) in one codebase.
Microservices: Separate services for Orders, Payments, and Inventory.

A monolithic and microservices architecture talks about how an application is distributed while a layered architecture refers more generally to how one might design the internal components of say a monolithic app or single microservice. In other words, just because it is a monolith does not mean it has a poor "layered" design. Likewise, just because you have a microservices architecture in place does not ensure that you have a perfectly "layered" codebase within it.

Types of Monolithic Architecture

Monolithic architectures can be categorized based on how they are structured internally and deployed. Here, we will explore different types of monolithic architectures, their advantages, disadvantages, and comparisons.

Layered (Tiered) Monolithic Architecture:

A Layered Monolithic Architecture (also called an N-Tier/ N-Layer architecture) is structured into distinct layers where each layer has a specific role. These layers interact with each other in a structured manner, typically in a hierarchical order.
It is one of the most commonly used architectural styles in enterprise applications.

Key Characteristics:

Divides an application into logical layers to improve modularity.
Each layer performs a specific function and interacts with adjacent layers.
Layers can be independently maintained, modified, and tested.
Encourages separation of concerns (SoC).

Common Layers in N-Layer Architecture
Though the number of layers can vary, a typical N-Layer Architecture consists of the following:

Presentation Layer (UI Layer)
- The topmost layer responsible for user interaction.
- Handles UI logic, input validation, and data display.
- Can be a web frontend (HTML, React, Angular, Vue) or a mobile app UI.
Application Layer (Service Layer)
- Serves as an intermediary between the UI and business logic.
- Contains service-level logic and orchestrates requests.
- Often implements APIs and application services.
Business Logic Layer (Domain Layer)
- Contains the core business rules and operations.
- Ensures business logic remains separate from other layers.
- Example: Order Processing, Payment Calculation, Inventory Management.
Data Access Layer (Persistence Layer)
- Responsible for database interactions (CRUD operations).
- Implements ORMs (e.g., Django ORM, Hibernate, Entity Framework).
- Encapsulates SQL queries to avoid direct database access.
Database Layer
- Stores and retrieves data.
- Can be relational (PostgreSQL, MySQL) or NoSQL (MongoDB, Firebase).
- Data is accessed only through the Data Access Layer.

Advantages of N-Layer Architecture

Separation of Concerns (SoC)
- Each layer has a clear responsibility.
- UI, business logic, and data access are kept independent.
Maintainability & Scalability
- Easy to update and expand without affecting other layers.
- Enhances modularity, making debugging and testing easier.
Code Reusability
- Business logic and data access can be reused across different applications.
- The API layer (Application Layer) can serve multiple frontends.
Security
- Direct database access from the UI is prevented.
- Sensitive logic is handled within the business layer.
Supports Different Frontends
- A REST API (Application Layer) can support both web and mobile applications.

Disadvantages of N-Layer Architecture

Performance Overhead
- Multiple layers introduce function call overhead.
- Increased latency due to inter-layer communication.
Complexity
- More layers lead to more code complexity.
- Not ideal for very simple applications.
Harder Deployment
- Updating a single layer may require redeploying the entire application.
- In microservices, layers might need independent deployments.

Example: N-Layer Architecture in a Django Web Application
Presentation Layer (UI): This layer handles user interactions.

<!-- templates/products.html -->
<h2>Product List</h2>
<ul>
  {% for product in products %}
    <li>{{ product.name }} - ${{ product.price }}</li>
  {% endfor %}
</ul>

Application Layer (Service Layer): Defines views and API controllers

# views.py (Application Layer)
from django.shortcuts import render
from .services import ProductService

def product_list(request):
    products = ProductService.get_all_products()
    return render(request, 'products.html', {'products': products})

Business Logic Layer: Contains domain logic for managing products.

# services.py (Business Logic Layer)
from .repositories import ProductRepository

class ProductService:
    @staticmethod
    def get_all_products():
        return ProductRepository.get_all()

Data Access Layer: Encapsulates database operations.

# repositories.py (Data Access Layer)
from .models import Product

class ProductRepository:
    @staticmethod
    def get_all():
        return Product.objects.all()

Database Layer: Stores product information.

# models.py (Database Layer)
from django.db import models

class Product(models.Model):
    name = models.CharField(max_length=255)
    price = models.DecimalField(max_digits=10, decimal_places=2)

+----------------------------------------------------+
|             Presentation Layer (UI)               |
|  - Web Frontend (React, Angular, Vue)            |
|  - Mobile UI (Flutter, Swift, Kotlin)            |
+----------------------------------------------------+
|             Application Layer (Service Layer)     |
|  - API Controllers (Django REST, Flask, Spring)  |
|  - Handles HTTP Requests, Security, and Routing  |
+----------------------------------------------------+
|             Business Logic Layer                  |
|  - Order Processing, Payment Calculation         |
|  - Business Rules, Domain Models                 |
+----------------------------------------------------+
|             Data Access Layer (DAL)               |
|  - ORM (Django ORM, Hibernate, SQLAlchemy)       |
|  - Database Queries and Transactions             |
+----------------------------------------------------+
|             Database Layer                        |
|  - PostgreSQL, MySQL, MongoDB                     |
|  - Stores Persistent Data                         |
+----------------------------------------------------+

When to Use N-Layer Architecture
✅ Best suited for:

Enterprise applications (E-commerce, Banking, HRMS).
Applications that require scalability and maintainability.
APIs that serve multiple frontends (Web, Mobile).
Complex applications with strict separation of concerns.

❌ Avoid for:

Small or simple applications (e.g., a personal blog).
High-performance real-time applications (e.g., gaming).

Modular Monolithic Architecture

Modular Monolithic Architecture is a design approach where an application remains monolithic (deployed as a single unit) but is structured into independent, well-defined modules. Unlike a traditional monolith, which tends to become tightly coupled and difficult to maintain, a modular monolithic system ensures high cohesion and low coupling between different business functionalities.

This architecture is often seen as a middle ground between a monolithic and microservices approach.

Key Characteristics:

✅ Single deployable unit: Unlike microservices, the entire application is packaged and deployed as one unit.
✅ Modular design: The application is divided into independent modules, each encapsulating a specific business function.
✅ Internal boundaries: Different modules communicate through well-defined interfaces (e.g., function calls, APIs).
✅ Loose coupling: Each module is independent, reducing dependencies between functionalities.
✅ Easier scalability: The monolith can be refactored into microservices when needed.

Structure of Modular Monolithic Architecture:

+----------------------------------------------------------+
|                 Modular Monolithic Application          |
| +----------------------------------------------------+  |
| |  Presentation Layer (UI)                          |  |
| |  - Web Frontend (React, Angular)                 |  |
| |  - Mobile Frontend (Flutter, Swift, Kotlin)      |  |
| +----------------------------------------------------+  |
| |  Application Layer (Service Layer)               |  |
| |  - API Endpoints (REST, GraphQL)                 |  |
| |  - Request Handling, Security, Authorization     |  |
| +----------------------------------------------------+  |
| |  Business Logic Layer                            |  |
| |  - Module 1: User Management                    |  |
| |  - Module 2: Orders                             |  |
| |  - Module 3: Payments                           |  |
| |  - Module 4: Inventory                          |  |
| |  (Each module has its own logic, repositories)  |  |
| +----------------------------------------------------+  |
| |  Data Access Layer (DAL)                        |  |
| |  - ORM (Django ORM, Hibernate, SQLAlchemy)      |  |
| |  - Repository Pattern                           |  |
| +----------------------------------------------------+  |
| |  Database Layer                                 |  |
| |  - PostgreSQL, MySQL, MongoDB                   |  |
+----------------------------------------------------------+

Explanation of Layers

Presentation Layer (UI):
- Manages user interactions.
- Can be a web UI (React, Angular) or mobile app (Flutter, Swift).
Application Layer (Service Layer):
- Manages API requests.
- Handles security, routing, and authorization.
Business Logic Layer (Modules):
- Divided into independent modules (User Management, Orders, Payments).
- Each module has its own logic and repository.
Data Access Layer (DAL):
- Uses an ORM (Django ORM, Hibernate, SQLAlchemy).
- Implements the Repository Pattern for database access.

Database Layer:

Stores persistent data.
Can be a single shared database or multiple databases per module.

Advantages of Modular Monolithic Architecture

✅ Maintainability & Scalability Since code is organized into independent modules, it's easier to modify and scale specific features.
✅ Performance Optimization No network overhead like microservices (direct function calls between modules).Faster than microservices for internal operations.
✅ Easier Deployment Unlike microservices, there's only one deployment unit, reducing operational complexity.
✅ Code Reusability Modules can be reused across different parts of the application.
✅ Easier Transition to Microservices If needed, each module can be extracted as a microservice in the future.

Challenges of Modular Monolithic Architecture

❌ Single Point of Failure If the monolith crashes, the entire application goes down.
❌ Scaling Limitations While modular, it’s still deployed as a single unit, making independent scaling of modules harder than microservices.
❌ Deployment Complexity in Large Applications A single bug in one module can require redeploying the entire application.

Example: Modular Monolithic Architecture in Django Let's implement a Modular Monolithic E-commerce System with Orders, Payments, and Users as modules.

Defining Modules

users/ → Manages users and authentication
orders/ → Manages product orders
payments/ → Handles payment processing

Directory Structure

ecommerce_project/
│── ecommerce/
│   ├── settings.py
│   ├── urls.py
│   ├── wsgi.py
│── users/
│   ├── models.py
│   ├── views.py
│   ├── services.py
│   ├── repositories.py
│── orders/
│   ├── models.py
│   ├── views.py
│   ├── services.py
│   ├── repositories.py
│── payments/
│   ├── models.py
│   ├── views.py
│   ├── services.py
│   ├── repositories.py
│── db.sqlite3
│── manage.py

Business Logic Implementation
Each module has:

Models (Database schema)
Services (Business logic)
Repositories (Database access)
Views (API Endpoints)

Orders Module Example

# orders/models.py
from django.db import models

class Order(models.Model):
    product_name = models.CharField(max_length=255)
    quantity = models.IntegerField()
    total_price = models.DecimalField(max_digits=10, decimal_places=2)

# orders/repositories.py
from .models import Order

class OrderRepository:
    @staticmethod
    def create_order(product_name, quantity, total_price):
        return Order.objects.create(product_name=product_name, quantity=quantity, total_price=total_price)

# orders/services.py
from .repositories import OrderRepository

class OrderService:
    @staticmethod
    def place_order(product_name, quantity, total_price):
        return OrderRepository.create_order(product_name, quantity, total_price)

# orders/views.py
from django.http import JsonResponse
from .services import OrderService

def create_order(request):
    order = OrderService.place_order("Laptop", 1, 1500.00)
    return JsonResponse({"order_id": order.id, "message": "Order created successfully!"})

When to Use Modular Monolithic Architecture
✅ Ideal for:

Medium to large applications that need maintainability.
Teams transitioning from monolith to microservices.
Applications requiring high performance with modularity.
Systems where deployment simplicity is preferred over complex microservices.

❌ Avoid if:

The system requires independent scaling of services.
Different teams need to work on separate deployable services.
The system is extremely large and complex.

Clean Architecture:

Clean Architecture is a software design pattern proposed by Robert C. Martin (Uncle Bob) that promotes separation of concerns and independence from frameworks, databases, and UI technologies.

It ensures that business logic is at the core of the system, and external dependencies like databases, APIs, or UI frameworks are kept at the outer layers, making the system flexible, testable, and maintainable.

Key Characteristics

✅ Independence from External Systems The core business logic does not depend on frameworks, databases, or UI.
✅ Separation of Concerns (SoC) Divides code into layers, ensuring that business logic is not mixed with infrastructure.
✅ Testability The system is highly testable since business rules do not depend on external layers.
✅ Flexibility for Future Changes Easy to switch databases, frameworks, or UI technologies without affecting core logic.
✅ Dependency Rule Inner layers should never depend on outer layers (dependencies always flow inward).

Structure of Clean Architecture

+------------------------------------------------------+
|                  UI / Presentation Layer            |  (Outer Layer - Depends on Application Layer)
|  - REST API, CLI, Web UI, Mobile UI                 |
+------------------------------------------------------+
|                  Application Layer                  |  (Application Rules - Uses Business Layer)
|  - Use Cases (Application-specific business logic)  |
+------------------------------------------------------+
|                  Domain / Business Layer            |  (Core Business Rules - Independent)
|  - Entities, Business Logic, Rules                  |
+------------------------------------------------------+
|                  Infrastructure Layer               |  (Outer Layer - Depends on Application Layer)
|  - Database (PostgreSQL, MongoDB)                   |
|  - API Clients, Third-Party Services                |
+------------------------------------------------------+

Explanation of Layers

Presentation Layer (UI Layer)
- Handles user interactions (Web, Mobile, CLI).
- Depends on Application Layer (calls Use Cases).
Application Layer (Use Cases Layer)
- Contains application-specific business logic.
- Calls the Domain Layer and provides results to UI.
Domain Layer (Core Business Rules)
- Contains Entities, Business Logic, Business Rules.
- Independent of frameworks, databases, APIs, and UI.
- The most critical layer—ensures stability.
Infrastructure Layer (External Dependencies)
- Implements database connections, APIs, third-party services.
- Provides repositories for data persistence.

Example: Clean Architecture in Django

ecommerce_project/
│── ecommerce/
│   ├── settings.py
│   ├── urls.py
│   ├── wsgi.py
│── domain/                    # Core Business Logic (Independent)
│   ├── entities/
│   │   ├── product.py
│   ├── interfaces/
│   │   ├── product_repository.py
│── application/                # Use Cases
│   ├── usecases/
│   │   ├── create_product.py
│── infrastructure/             # External Dependencies
│   ├── repositories/
│   │   ├── product_repository.py
│   ├── database/
│   │   ├── models.py
│── presentation/               # UI / REST API
│   ├── views/
│   │   ├── product_views.py
│── db.sqlite3
│── manage.py

Business Logic (Domain Layer)
The core business logic should not depend on external systems.

# domain/entities/product.py
class Product:
    def __init__(self, name: str, price: float):
        self.name = name
        self.price = price

    def update_price(self, new_price: float):
        if new_price < 0:
            raise ValueError("Price cannot be negative")
        self.price = new_price

Repository Interface
Defines how data should be accessed without depending on any database.

# domain/interfaces/product_repository.py
from abc import ABC, abstractmethod

class ProductRepository(ABC):
    @abstractmethod
    def save(self, product):
        pass

    @abstractmethod
    def get_all(self):
        pass

Use Case (Application Layer)
Implements business operations like creating a product.

# application/usecases/create_product.py
from domain.entities.product import Product
from domain.interfaces.product_repository import ProductRepository

class CreateProductUseCase:
    def __init__(self, repository: ProductRepository):
        self.repository = repository

    def execute(self, name: str, price: float):
        product = Product(name, price)
        self.repository.save(product)
        return product

Infrastructure Layer
Implements the Repository Interface using Django ORM.

# infrastructure/repositories/product_repository.py
from domain.interfaces.product_repository import ProductRepository
from infrastructure.database.models import ProductModel

class DjangoProductRepository(ProductRepository):
    def save(self, product):
        ProductModel.objects.create(name=product.name, price=product.price)

    def get_all(self):
        return ProductModel.objects.all()

Django ORM Model:

# infrastructure/database/models.py
from django.db import models

class ProductModel(models.Model):
    name = models.CharField(max_length=255)
    price = models.DecimalField(max_digits=10, decimal_places=2)

Presentation Layer (API)
REST API for creating products.

# presentation/views/product_views.py
from django.http import JsonResponse
from application.usecases.create_product import CreateProductUseCase
from infrastructure.repositories.product_repository import DjangoProductRepository

def create_product(request):
    repository = DjangoProductRepository()
    use_case = CreateProductUseCase(repository)
    product = use_case.execute("Laptop", 1500.00)
    return JsonResponse({"product_name": product.name, "price": product.price})

Advantages of Clean Architecture

✅ Independence from Frameworks Business logic remains decoupled from Django, Flask, or any other framework.
✅ Easy to Replace Technologies UI (React, Flutter) and Database (PostgreSQL, MongoDB) can be changed without affecting business logic.
✅ Better Maintainability Code is well-structured, making debugging and scaling easier.
✅ Highly Testable Business logic can be tested without a database or external dependencies.

Challenges of Clean Architecture

❌ Increased Complexity More layers = more code and boilerplate.
❌ Slower Development Speed Initially Requires defining interfaces, entities, repositories.
❌ Overkill for Small Projects Not suitable for simple applications like a personal blog.

When to Use Clean Architecture
✅ Best suited for:

Enterprise Applications (E-commerce, Banking, HRMS).
Applications that require scalability and maintainability.
Systems expected to evolve with changing UI or databases.
Large teams working on different modules independently.

❌ Avoid if:

The project is small and does not require strict separation of concerns.
Development speed is more critical than maintainability.

Microservices Architecture:

Microservices Architecture is a software design pattern where an application is built as a collection of loosely coupled, independently deployable services, each responsible for a specific business capability.

Unlike Monolithic Architecture, where all functionalities exist within a single codebase, Microservices promote scalability, flexibility, and resilience.

Key Characteristics of Microservices

✅ Decentralization Each service has its own database and logic.
✅ Independent Deployment Services can be updated or deployed without affecting the entire system.
✅ Technology Agnostic (Polyglot Architecture) Services can be built using different programming languages, databases, and frameworks.
✅ Scalability Each service can scale independently based on demand.
✅ Resilience and Fault Tolerance Failure in one service does not bring down the entire system.
✅ Bounded Context (Domain-Driven Design) Each service corresponds to a specific domain (e.g., Orders, Payments, Users).

Microservices Architecture Diagram

+----------------------------------------------------+
|              API Gateway / Load Balancer          |
+----------------------------------------------------+
| Users | Orders | Payments | Inventory | Notifications |
+----------------------------------------------------+
|      Independent Databases for Each Service      |
+----------------------------------------------------+

Key Design Patterns in Microservices

Database per Service Pattern / Polyglot Persistence
Each microservice manages its own database, preventing direct access by other services.
Each microservice uses the best database technology for its needs.
- ✅ Advantages:
  - Ensures data isolation and reduces coupling.
  - Allows each service to choose the best database technology.
  - Optimized performance for specific use cases.
  - Avoids one-size-fits-all database constraints.
- ❌ Challenges
  - Requires data synchronization strategies (e.g., Event Sourcing, CQRS).
  - Data consistency is difficult across different databases.
  Example:
  - User Service → PostgreSQL
  - Orders Service → MySQL
  - Payments Service → MongoDB
Decomposition Patterns
Breaking a monolithic system into microservices requires careful planning.
Two main decomposition strategies:
- Decomposition by Business Capability
  Each microservice handles a specific business domain.
  - ✅ Example:
    - User Service: Manages authentication & user profiles.
    - Order Service: Handles order creation & tracking.
    - Payment Service: Processes payments & transactions.
- Decomposition by Subdomains (Bounded Context)
  Follows Domain-Driven Design (DDD) where each microservice corresponds to a bounded context.
  - ✅ Example of Bounded Contexts in an E-commerce App:
    - Customer Context (User Management, Authentication)
    - Order Context (Order Placement, Tracking)
    - Payment Context (Billing, Refunds)
    - Shipping Context (Delivery, Logistics)
      Each context has its own domain model and database.

Microservices Communication Patterns

Microservices architecture divides applications into loosely coupled, independently deployable services. The way these services communicate is crucial for system reliability, scalability, and maintainability. Let's explore the major communication patterns with Python examples.

Synchronous Communication Patterns

Request-Response / RESTful HTTP (JSON over HTTP)
This is the most straightforward pattern where a client sends a request and waits for a response.
Use case: Service A calls Service B and expects an immediate result.

  # Service A - Making request
  import requests

  def get_user_data(user_id):
      response = requests.get(f"http://user-service/users/{user_id}")
      if response.status_code == 200:
          return response.json()
      else:
          return {"error": "User not found"}

  # Service B - Handling request
  from flask import Flask, jsonify

  app = Flask(__name__)

  @app.route("/users/<user_id>", methods=["GET"])
  def get_user(user_id):
      # Fetch user from database
      user = {"id": user_id, "name": "John Doe", "email": "john@example.com"}
      return jsonify(user)

  if __name__ == "__main__":
      app.run(host="0.0.0.0", port=5000)


  # order_service/order.py
  import requests

  def create_order(order_data):
      # Call Payment Service
      payment_response = requests.post("http://payment-service/api/pay", json={
          "order_id": order_data["id"],
          "amount": order_data["amount"]
      })

      if payment_response.status_code == 200:
          return {"status": "Order placed"}
      else:
          return {"status": "Payment failed"}

Advantages:
- Simple to implement and understand
- Immediate feedback on success/failure
- Easy to test and monitor
- Well-established standards and tooling
- Stateless operations improve scalability
- Resource-oriented approach is intuitive
Disadvantages:
- Creates tight coupling between services
- Blocking operations affect performance / Latency issues if services are down
- Potential for cascading failures

gRPC (Google Remote Procedure Call)
Use case: High-performance inter-service communication with strongly typed contracts.
gRPC uses HTTP/2 and Protocol Buffers for efficient, strongly-typed RPC calls.

  // payment.proto
  syntax = "proto3";

  service PaymentService {
    rpc Pay (PaymentRequest) returns (PaymentResponse);
  }

  message PaymentRequest {
    string order_id = 1;
    float amount = 2;
  }

  message PaymentResponse {
    string status = 1;
  }

  # Compile Proto File
  python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. payment.proto

  # order_service/order.py
  import grpc
  import payment_pb2
  import payment_pb2_grpc

  def pay():
      channel = grpc.insecure_channel("localhost:50051")
      stub = payment_pb2_grpc.PaymentServiceStub(channel)
      response = stub.Pay(payment_pb2.PaymentRequest(order_id="123", amount=50.0))
      return response.status

Advantages:
- Highly efficient binary protocol
- Strong typing ensures contract adherence
- Bidirectional streaming support
- Generated client libraries
Disadvantages:
- Requires schema definition upfront
- More complex setup than REST

Asynchronous Communication Patterns

Message Queue Pattern
Services communicate by sending messages through queues, decoupling senders from receivers.
Use case: Fire-and-forget style communication or event-driven systems.
Scenario: Order Service sends an "OrderCreated" event → Inventory Service listens and updates stock.
Example using RabbitMQ and Pika:

🛠 Install RabbitMQ First:

# Docker Run RabbitMQ (Management UI on :15672)
docker run -d --hostname rabbit --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3- 
management

Order Service (Publisher)

# order_service/publisher.py
import pika
import json

def publish_order_created(order_id, product_id):
    connection = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
    channel = connection.channel()

    channel.queue_declare(queue="order_created")

    message = {
        "order_id": order_id,
        "product_id": product_id
    }
    channel.basic_publish(
        exchange="",
        routing_key="order_created",
        body=json.dumps(message)
    )
    print("Published Order Created Event")
    connection.close()

Inventory Service (Consumer)

# inventory_service/consumer.py
import pika
import json

def callback(ch, method, properties, body):
    data = json.loads(body)
    print(f"Inventory updated for product: {data['product_id']} due to order: 
{data['order_id']}")

connection = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = connection.channel()
channel.queue_declare(queue="order_created")

channel.basic_consume(queue="order_created", on_message_callback=callback, auto_ack=True)
print("Waiting for messages. To exit press CTRL+C")
channel.start_consuming()

Advantages:
- Decouples services temporally
- Provides buffer during traffic spikes
- Service can process messages at their own pace
- Improves fault tolerance
- Higher availability (services don’t need to be up at the same time)
- Enables event-driven architecture
Disadvantages:
- Eventual consistency challenges
- More complex architecture
- Harder to debug and trace
- More complex error handling & retry logic
- Needs message ordering strategies

Request-Reply over Message Queue
Sometimes you want asynchronous communication but need a response eventually. RabbitMQ allows you to set up callback queues for replies.
This is more advanced and usually handled using frameworks like Celery or RPC patterns over message brokers.
In Request-Reply (also known as RPC over messaging), one service (the client/requester) sends a message to another service (the server/responder) and waits for a reply — but the communication is handled asynchronously via a message broker like RabbitMQ, Kafka, or ZeroMQ.
This pattern is commonly used when:

You want loose coupling between services.
You still need to get a response or result back.
You want reliability and retry mechanisms baked in.

🧭 Workflow Overview

Client sends a message to a request queue.
It sets a reply_to queue and a correlation_id to track the response.
Server processes the message and sends a response to the reply_to queue.
Client listens to the reply queue and matches the correlation_id.

🛠 Let’s Build It Using RabbitMQ and Python (with pika)
We'll create two services:

Client Service: Sends a request and waits for a reply.
Worker Service: Processes the request and replies with a result.

📦 Step 1: Install RabbitMQ and Pika

pip install pika
docker run -d --hostname my-rabbit --name some-rabbit \
-p 5672:5672 -p 15672:15672 rabbitmq:3-management

📡 Step 2: The Server (Worker) Code

# rpc_server.py
import pika
import json

def process_task(n):
    # Simulate computation (e.g., square the number)
    return n * n

connection = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = connection.channel()

channel.queue_declare(queue='rpc_queue')

def on_request(ch, method, props, body):
    request = json.loads(body)
    print("Received request:", request)

    n = request.get("number", 0)
    result = process_task(n)

    response = json.dumps({"result": result})

    ch.basic_publish(
        exchange='',
        routing_key=props.reply_to,  # Send reply to client's reply queue
        properties=pika.BasicProperties(correlation_id=props.correlation_id),
        body=response
    )

    ch.basic_ack(delivery_tag=method.delivery_tag)

channel.basic_qos(prefetch_count=1)
channel.basic_consume(queue='rpc_queue', on_message_callback=on_request)

print("[x] Awaiting RPC requests")
channel.start_consuming()

🤖 Step 3: The Client (Requester) Code

# rpc_client.py
import pika
import uuid
import json

class RpcClient:
    def __init__(self):
        self.connection = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
        self.channel = self.connection.channel()

        # Create a temporary queue for replies
        result = self.channel.queue_declare(queue='', exclusive=True)
        self.callback_queue = result.method.queue

        self.channel.basic_consume(
            queue=self.callback_queue,
            on_message_callback=self.on_response,
            auto_ack=True
        )

        self.response = None
        self.correlation_id = None

    def on_response(self, ch, method, props, body):
        if props.correlation_id == self.correlation_id:
            self.response = json.loads(body)

    def call(self, number):
        self.response = None
        self.correlation_id = str(uuid.uuid4())

        request_data = json.dumps({"number": number})

        self.channel.basic_publish(
            exchange='',
            routing_key='rpc_queue',
            properties=pika.BasicProperties(
                reply_to=self.callback_queue,
                correlation_id=self.correlation_id,
            ),
            body=request_data
        )

        # Wait for response
        while self.response is None:
            self.connection.process_data_events()

        return self.response

# Test the RPC
rpc = RpcClient()
print("[x] Requesting square of 8")
response = rpc.call(8)
print("[.] Got:", response)

🧩 Key Concepts in the Code

reply_to: Tells the server where to send the reply
correlation_id: A unique ID used by the client to match a request with its response
exclusive=True: Makes sure the reply queue is private to this client
auto_ack=True: Automatically acknowledges message receipt (safe since only the client uses it)

✅ Advantages

✅ Loose Coupling: Services communicate indirectly via queues.
✅ Retry & Durability: Messages are buffered, no data loss if one service is down temporarily.
✅ Scalability: Multiple workers can consume from the same request queue.
✅ Language-Agnostic: Works across platforms and programming languages.

❌ Challenges

❌ Latency: More overhead compared to direct REST/gRPC.
❌ Correlation Management: Needs handling of correlation_id.
❌ Temporary Queues: If not managed well, they can become stale or leak.
❌ Complexity: Harder to debug than direct calls.

🧠 Where is Request-Reply over MQ Used?

Payment gateways (e.g., wait for transaction response)
Fraud detection services (send request, wait for fraud risk score)
Machine learning inference systems (submit input, get prediction)
Reporting (submit report job, get result when ready)

SOFTWARE ARCHITECTURE

Basic Design Principles

Software Architecture

Architecture vs. Design

Architectural Qualities and Concerns

Basic Architectural Styles

Design Patterns

Monolithic Architecture:

Types of Monolithic Architecture

Layered (Tiered) Monolithic Architecture:

Modular Monolithic Architecture

Clean Architecture:

Microservices Architecture:

Key Design Patterns in Microservices

Microservices Communication Patterns

Synchronous Communication Patterns

Asynchronous Communication Patterns

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally