Skip to main content

Database Component

The Database component is the final destination in your system design, representing where data is stored and retrieved. In our platform, the Database component serves as the signal that your architecture is complete and ready for execution.

Overview​

Every complete system design needs a Database component. It tells the simulation engine that your data flow circuit is closed and ready to execute. When the simulation reaches the Database, it triggers the backend execution that processes your request and returns results.

Real-World Parallel

Think of the Database as the warehouse in a delivery system:

  • User Request = Customer places an order
  • Load Balancer = Distribution center routes to available facilities
  • API Service = Processing center validates and packages the order
  • Database = Warehouse stores and retrieves inventory

Without the warehouse (Database), the entire system can't function - there's nowhere for the data to go!

Why Database is Required​

The Database component serves two critical purposes in our platform:

1. Completes the Circuit​

Your system design is like an electrical circuit - it needs to be complete for current to flow. The Database component closes this circuit, signaling that your architecture is ready for simulation.

✅ Complete Circuit:
User Request → API Service → Database

❌ Incomplete Circuit:
User Request → API Service → (nowhere to go)

2. Triggers Backend Execution​

When the simulation reaches a Database component, it sends the entire request to the backend for processing. This is when:

  • Custom API Service code executes
  • Data validation occurs
  • Database operations (INSERT/UPDATE/DELETE) happen
  • Results are returned to your frontend

Current Capabilities​

The Database component currently provides:

Basic Configuration:

  • Component name (customizable)
  • Type identifier (Database)
  • Unique component ID

Simulation Features:

  • Receives data from API Services or User Requests
  • Stores data in session-scoped collections
  • Supports all CRUD operations (Create, Read, Update, Delete)
  • Automatic table creation based on API Service column definitions
  • Session isolation (your data doesn't mix with other users)
Current Status

The Database component currently has minimal configuration options. We're actively developing additional features to make it more powerful and realistic. See Future Enhancements for what's coming!

How Database Works in Simulations​

Basic Flow​

API Service → Database
    ↓
Backend Execution:
1. Process request
2. Execute custom code (if any)
3. Perform database operation
4. Return results

What Happens at the Database​

When your simulation reaches the Database component:

  1. Connection Phase

    ℹ️  Database: DB-1
    ℹ️  Status: Connecting...
    ✅ Status: Connected

  2. Execution Path Logged

    ℹ️  Execution path: UR-1 --> API-1 --> DB-1

  3. Backend Processing

    ℹ️  Status: Sending to backend...
    ℹ️  Sending simulation request to the server..
    ℹ️  Request succeeded. Processing response.

  4. Results Returned

    ✅ UR-1 POST completed successfully
    ✅ Response: {"operation": "INSERT", "record_id": "abc123", ...}

Setting Up Database Component​

Basic Setup​

Step 1: Add Database component to your canvas

Step 2: Connect it to an API Service or User Request

User Request → Database  (simple, no business logic)
User Request → API Service → Database  (with validation/transformation)

Step 3: Run simulation

That's it! The Database requires no additional configuration to work.

Architecture Examples​

Simple CRUD System​

┌──────────────┐
│ User Request │
│  POST /users │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   Database   │
└──────────────┘

With Business Logic​

┌──────────────┐
│ User Request │
│  POST /users │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ API Service  │
│  (Validate   │
│   Email)     │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   Database   │
└──────────────┘

Load Balanced System​

┌──────────────┐
│ User Request │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│Load Balancer │
└───┬─────┬────┘
    │     │
    ▼     ▼
┌────┐  ┌────┐
│API1│  │API2│
└──┬─┘  └──┬─┘
   │       │
   └───┬───┘
       ▼
   ┌────────┐
   │Database│
   └────────┘

Data Storage​

Data Isolation and Storage​

All simulation data is automatically isolated per session:

  • Your data is private - Each session has its own isolated storage
  • Safe testing environment - Your experiments won't affect other users
  • Automatic cleanup - Data is removed when you delete your design
  • Persistent within session - Data remains available throughout your session for testing

This means you can safely create, test, and iterate on your system designs without worrying about data conflicts or privacy concerns.

Supported Operations​

The Database supports standard CRUD operations:

OperationHTTP MethodWhat It Does
CREATEPOSTInserts new records with auto-generated or custom IDs
READGETRetrieves all records or specific record by ID
UPDATEPUTModifies existing record by ID
DELETEDELETERemoves record by ID or all records

Automatic Table Creation​

When an API Service performs an INSERT operation with new columns, the Database automatically creates the table structure:

# API Service returns:
{
    'operation': 'INSERT',
    'columns': [
        {'name': 'email', 'type': 'TEXT'},
        {'name': 'age', 'type': 'INTEGER'}
    ],
    'data': {
        'email': 'user@example.com',
        'age': 25
    }
}

# Database automatically creates 'users' table (if from /api/users endpoint)

Integration with Other Components​

With User Request (Direct)​

Connection:

User Request → Database

Use case: Simple CRUD operations without validation or transformation

Example: Basic data storage where the User Request endpoint and properties directly map to database fields

With API Service​

Connection:

API Service → Database

Use case: Add business logic, validation, or transformation before storage

Example: Validate email format, check for duplicates, generate custom IDs

With Load Balancer​

Indirect Connection:

Load Balancer → API Service → Database

Use case: Distribute traffic across multiple API Service instances

Note: Multiple API Services can share the same Database

Component Properties​

The Database component displays basic information:

Properties shown:

  • Type: Database (DB)
  • Name: Automatically assigned (e.g., "Database-1", "Database-2")
  • ID: Unique identifier (first 8 characters shown)
info

Component names are currently auto-generated and numbered sequentially. Custom naming is planned for a future update to help you organize complex architectures with multiple databases.

Practical Examples​

Example 1: Simple User Storage​

Goal: Store user data without validation

Setup:

User Request (POST /api/users) → Database

User Request Properties:

name: "John Doe"
email: "john@example.com"

What happens:

  1. User Request sends data directly to Database
  2. Database creates "users" table automatically
  3. Data is inserted with auto-generated ID
  4. Record ID is returned

Example 2: Validated User Registration​

Goal: Validate email before storing

Setup:

User Request (POST /api/users) → API Service → Database

API Service Code:

import re

def process_request(input_data):
    data = input_data.get('data', {})
    email = data.get('email', '')

    # Validate email format
    if not re.match(r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$', email):
        return {
            'operation': 'NONE',
            'error': 'Invalid email format'
        }

    # Store in database
    return {
        'operation': 'INSERT',
        'columns': [
            {'name': 'name', 'type': 'TEXT'},
            {'name': 'email', 'type': 'TEXT'}
        ],
        'data': data
    }

Flow:

  1. User Request → API Service (validates email)
  2. If valid → API Service → Database (stores data)
  3. If invalid → Returns error without storing

Example 3: Multi-Server Architecture​

Goal: Demonstrate load balancing with shared database

Setup:

User Request → Load Balancer → API Service 1 → Database
                              → API Service 2 → Database
                              → API Service 3 → Database

Result:

  • Requests are distributed across 3 API Services
  • All API Services write to the same Database
  • Data is accessible regardless of which server processed the request

Error Handling​

Common Errors​

"No database connected"​

Cause: API Service or User Request has no outgoing connection to a Database

Solution: Draw a connection from your API Service (or User Request) to a Database component

Example:

❌ API Service (no connection)
✅ API Service → Database

"Error processing request"​

Cause: Backend execution failed (usually due to API Service code error)

Solution: Check your API Service code for:

  • Syntax errors
  • Missing required fields (operation, columns for INSERT/UPDATE)
  • Invalid column types
  • Print statements (must be removed)

Viewing Database Contents​

After running simulations, you can query your data:

GET All Records​

Setup:

User Request (GET /api/users) → Database

Result: Returns all records from the "users" table

GET Specific Record​

Setup:

User Request (GET /api/users/abc123) → Database

Result: Returns the record with ID "abc123"

With API Service​

You can also query through an API Service for transformation:

User Request (GET /api/users) → API Service → Database

API Service Code:

def process_request(input_data):
    existing = input_data.get('existing_records', [])

    # Transform data before returning
    active_users = [
        user for user in existing
        if user.get('is_active') == True
    ]

    # For GET requests, we still return existing records
    # The transformation is just for display
    return {
        'operation': 'NONE',  # No database modification
        'data': active_users
    }

Best Practices​

  1. Always Include Database - Every complete system design needs at least one Database component

  2. Connect API Services First - For most designs, connect API Services to Database rather than User Requests directly

  3. Test Data Flow - Run GET requests after POST/PUT to verify data was stored correctly

  4. Session Isolation - Remember that each session has its own data - use this for safe testing

Current Limitations​

Early Development Stage

We're in the early phases of building this platform. The Database component currently has minimal configuration options, but we're actively working on powerful new features!

Current limitations:

  • No database type selection (SQL vs NoSQL)
  • No query customization options
  • No index configuration
  • No performance metrics
  • No replication settings
  • No backup/restore features

These limitations don't affect your ability to learn system design concepts, but we're excited to add more realism in future updates!

Future Enhancements​

We're taking a thoughtful, step-by-step approach to building this platform. As we continue to develop the Database component, we're exploring features that will make it more powerful and realistic for learning system design concepts.

We're committed to delivering quality features that truly help you learn, rather than rushing to add everything at once. Stay tuned for updates as we continue to improve the platform!

Use Cases​

Learning System Design​

  • Understand data persistence patterns
  • Practice CRUD operations
  • Design database schemas
  • Learn about data flow

Interview Preparation​

  • Demonstrate data modeling skills
  • Discuss scaling strategies

Architecture Planning​

  • Visualize system dependencies
  • Test different data flows

Our Mission​

Our goal is to help you become proficient at designing systems. Whether you're:

  • Building your first system - Use our platform to simulate and test before writing production code
  • Preparing for interviews - Practice system design questions with real execution
  • Learning new concepts - Experiment with load balancing, caching, and scaling patterns
  • Teaching others - Demonstrate architectural patterns visually

We hope to be your guide throughout your system design journey. We're committed to adding more features and making this the most comprehensive system design simulation platform available.

Troubleshooting​

Database doesn't execute​

  • Check: Is Database connected to an API Service or User Request?
  • Check: Is your entire flow complete (User Request → ... → Database)?

Data not persisting​

  • Check: Are you in the same session? Data is session-scoped
  • Check: Did the simulation complete successfully? Check logs for errors

Can't see stored data​

  • Solution: Run a GET request to the same endpoint to retrieve data
  • Example: After POST /api/users, run GET /api/users

Multiple databases showing same data​

  • Cause: All databases in a session currently share the same storage
  • Current Status: This is expected behavior

Next Steps​

Share Your Feedback

We're actively building this platform and would love to hear from you! Your feedback helps us prioritize features and improvements. Use the feedback button to let us know what features you'd like to see next.