Building Multi Component Systems

Introduction to Multi-Component Features

Architecture: Thinking Beyond the Database

When building multi-component systems, the API acts like a traffic controller. It doesn't do all the work itself; instead, it tells other components what to do. For Task Attachments, we need a Storage Strategy . We don't want to just dump every file into one big folder. We organize them so they are easy to find and manage. Component Responsibility Example Database Stores information about the file. File name: contract.pdf, Size: 2MB Mock S3 Storage Stores the actual file data. A file located at /attachments/task-123/contract.pdf Validators Checks if the file is safe and allowed. Is this file larger than 5MB? One new concept we use here is a Presigned URL . Since we want our files to be private and secure, we don't give users a permanent link to the file. Instead, when a user asks to see an attachment, our system generates a special link that expires after 1 hour . This ensures that only authorized users can see the files. Production Note: Real presigned URLs (like AWS S3's) use cryptographic signatures generated by the cloud SDK. They contain hash-based authentication that verifies the request came from an authorized source. Our mock implementation simplifies this to a basic URL format for learning purposes only.

Component	Responsibility	Example
`Database`	Stores information about the file.	File name: `contract.pdf`, Size: `2MB`
`Mock S3 Storage`	Stores the actual file data.	A file located at `/attachments/task-123/contract.pdf`
`Validators`	Checks if the file is safe and allowed.	`Is this file larger than 5MB?`

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Generating the Phased Technical Plan

Before writing any code, we must ask Claude Code to generate a Technical Plan. This plan maps out exactly how the 13 tasks will be distributed across 5 phases. We provide Claude with our specification.md and ask it to follow our decomposition principles.

You would prompt Claude like this: "Given the approved specification for task attachments, generate a technical plan for a task management system. Use simplified Python classes (not production FastAPI). We'll mock external services (S3, virus scanner) for the learning environment."

Claude will then produce a plan divided into these phases:

Phase 1: Foundation. Creating the Attachment database model.
Phase 2: Storage Infrastructure. Building the S3Client to talk to the cloud (mocked for this environment).
Phase 3: Validation. Building services to check file types and scan for viruses.
Phase 4: API Integration. Creating the endpoints where the user actually uploads the file.
Phase 5: Testing. Running end-to-end tests to make sure a file uploaded by a user actually reaches S3 and the database correctly.

The following diagram visualizes these phases and their dependencies:

text

Phase 1: Foundation
└── Database Model
    ├──> Phase 2: Storage Infrastructure
    │    └── Mock S3 Client ────┐
    │                           │
    └──> Phase 3: Validation    │
         └── File Type & ───────┤
             Virus Checks       │
                                ▼
                         Phase 4: API Integration
                         └── Upload/Download Controllers
                             │
                             ▼
                         Phase 5: Testing
                         └── End-to-End Validation

Legend:
  ──> : Dependency path (sequential)
  ──┤ : Merge point (both Phase 2 and 3 feed into Phase 4)

Notice how Phase 2 and Phase 3 both depend only on Phase 1, meaning they can be developed in parallel. This is a key optimization opportunity in the workflow.

Executing the 13-Task Workflow

Task ID	Component	Phase	Dependencies	Can run in parallel?
`T001`	`Attachment Model`	`1`	None	No (Start here)
`T003`	`Mock S3Client`	`2`	None	Yes (With Phase 1)
`T005`	`MIME Validator`	`3`	None	Yes (With Phase 2)
`T008`	`Attachment Service`	`4`	`T002`, `T003`, `T005`	No (Needs components)

Now we begin execution. We will build the system step-by-step. First, we need a way to represent the attachment in our code.

Step 1: The Database Model

We define what information we want to save about a file.

Python

class Attachment:
    def __init__(self, id, task_id, filename, file_size, s3_key):
        self.id = id
        self.task_id = task_id
        self.filename = filename
        self.file_size = file_size
        self.s3_key = s3_key  # The address of the file in storage

This simple class tells our application that every attachment needs a name, a size, and an s3_key (the unique ID for the file in storage).

Step 2: The Mock S3 Client

Next, we need a component that handles the actual upload. In this learning environment, we mock (simulate) the S3 service so we don't need a real internet connection to test our code.

Python

class S3Client:
    def __init__(self):
        self.storage = {}  # Mock storage using a dictionary
    
    def upload_file(self, file_data, s3_key):
        # Simulate uploading to cloud storage
        print(f"Uploading file to: {s3_key}")
        self.storage[s3_key] = file_data
        return True

    def generate_presigned_url(self, s3_key):
        # MOCK ONLY: Real presigned URLs use cryptographic signing (HMAC-SHA256)
        # Production: aws_client.generate_presigned_url('get_object', Params={'Bucket': ..., 'Key': ...})
        return f"https://mock-s3.example.com/{s3_key}?expires=3600"

Note: In production code, replace print() statements with proper logging (e.g., logger.info(f"Uploading file to: {s3_key}")) to enable appropriate log levels, filtering, and integration with monitoring systems.

The upload_file method handles the heavy lifting, while generate_presigned_url creates that secure, temporary link we discussed earlier. In production environments, the cloud SDK's presigning mechanism uses cryptographic algorithms to create verifiable, tamper-proof URLs that expire after the specified time.

Step 3: The Attachment Service (Integration)

Finally, we create a service that brings the database and the storage together. This is where the coordination happens.

Python

class AttachmentService:
    def __init__(self, db_repo, s3_client):
        self.db_repo = db_repo
        self.s3_client = s3_client

    def process_upload(self, task_id, filename, file_data):
        # 1. Upload to cloud storage
        s3_key = f"tasks/{task_id}/{filename}"
        self.s3_client.upload_file(file_data, s3_key)
        
        # 2. Save metadata to database
        new_attachment = Attachment(None, task_id, filename, len(file_data), s3_key)
        return self.db_repo.save(new_attachment)

By passing the db_repo and s3_client into the service, we allow it to use both tools to complete the upload. This is a professional pattern called Dependency Injection.

text

Output from process_upload:
Uploading file to: tasks/101/report.pdf
Attachment saved to database with ID: 1

Introduction to Multi-Component Features

Architecture: Thinking Beyond the Database

Join the 1M+ learners on CodeSignal

Generating the Phased Technical Plan

Mapping Dependencies and Parallel Paths

Executing the 13-Task Workflow

Summary and Next Steps