Building Multi Component Features

Introduction to Multi-Component Features

In our previous lessons, we focused on building individual features like task comments . Those tasks were mostly local to our application — they involved a single database table and a few simple API rules . However, professional software often requires Multi-Component Features . These are features where the application must coordinate with external systems, such as cloud storage or third-party security tools . The Task Attachments feature is a perfect example. To allow users to upload files to a task, we cannot simply save the file in a database . We need to: Store the actual file in a cloud storage bucket (like Amazon S3). Save the metadata (the file's name, size, and type) in our database . Check the file for viruses and size limits before saving it. Provide a secure way for users to download it later. Because there are so many moving parts, we use Phased Decomposition . Instead of trying to build everything at once, we group tasks into logical phases. This keeps the AI focused and ensures that the foundation of the system is solid before we build the complex API layers on top.

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 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.

Component	Responsibility	Example
`Database`	Stores information about the file.	File name: `contract.pdf`, Size: `2MB`
`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?`

Generating the Phased Technical Plan

Before writing any code, we must ask Codex to generate a Technical Plan . This plan maps out exactly how the 13 tasks will be distributed across 5 phases . We provide Codex with our specification.md and ask it to follow the patterns in our CODEX.md file. You would prompt Codex like this: "Given the approved specification for task attachments, generate a technical plan for TaskMaster . Reference CODEX.md for our coding patterns and existing database conventions." Codex 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. 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: Phase 1: Foundation └── Database Model ├──> Phase 2: Storage Infrastructure │ └── S3 Client ──┐ │ │ └──> Phase 3: Validation │ └── File Type & ───────┤ Virus Checks │ ▼ Phase 4: API Integration └── Upload/Download Endpoints │ ▼ 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.

Join the 1M+ learners on CodeSignal

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

Executing the 13-Task Workflow

Task ID	Component	Phase	Dependencies	Can run in parallel?
`T001`	`Attachment Model`	`1`	None	No (Start here)
`T003`	`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 using a proper SQLAlchemy declarative model, consistent with the rest of the codebase.

Python

# src/models/attachment.py
from sqlalchemy import Column, Integer, String, BigInteger, ForeignKey
from sqlalchemy.orm import relationship
from src.database import Base

class Attachment(Base):
    __tablename__ = "attachments"

    id = Column(Integer, primary_key=True)
    task_id = Column(Integer, ForeignKey("tasks.id"), nullable=False)
    filename = Column(String, nullable=False)
    file_size = Column(BigInteger, nullable=False)
    s3_key = Column(String, nullable=False)  # The address of the file in the cloud

    # Relationships
    task = relationship("Task", back_populates="attachments")

# src/models/attachment.py
from sqlalchemy import Column, Integer, String, BigInteger, ForeignKey
from sqlalchemy.orm import relationship
from src.database import Base

class Attachment(Base):
    __tablename__ = "attachments"

    id = Column(Integer, primary_key=True)
    task_id = Column(Integer, ForeignKey("tasks.id"), nullable=False)
    filename = Column(String, nullable=False)
    file_size = Column(BigInteger, nullable=False)
    s3_key = Column(String, nullable=False)  # The address of the file in the cloud

    # Relationships
    task = relationship("Task", back_populates="attachments")

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

Step 2: The Attachment Repository

Following the repository pattern from CODEX.md, all database access goes through a repository class. The create() method persists an Attachment using the standard SQLAlchemy session flow.

Python

# src/repositories/attachment_repository.py
from sqlalchemy.orm import Session
from src.models.attachment import Attachment

class AttachmentRepository:
    def __init__(self, db: Session):
        self.db = db

    def create(self, task_id: int, filename: str, file_size: int, s3_key: str) -> Attachment:
        attachment = Attachment(
            task_id=task_id,
            filename=filename,
            file_size=file_size,
            s3_key=s3_key
        )
        self.db.add(attachment)
        self.db.commit()
        self.db.refresh(attachment)
        return attachment

# src/repositories/attachment_repository.py
from sqlalchemy.orm import Session
from src.models.attachment import Attachment

class AttachmentRepository:
    def __init__(self, db: Session):
        self.db = db

    def create(self, task_id: int, filename: str, file_size: int, s3_key: str) -> Attachment:
        attachment = Attachment(
            task_id=task_id,
            filename=filename,
            file_size=file_size,
            s3_key=s3_key
        )
        self.db.add(attachment)
        self.db.commit()
        self.db.refresh(attachment)
        return attachment

Step 3: The S3 Client (Mocked)

Next, we need a component that handles the actual upload. On CodeSignal and in development, we often mock (simulate) the S3 service so we don't need a real internet connection to test our code.

Python

class S3Client:
    def upload_file(self, file_data, s3_key):
        # In a real app, this sends data to Amazon
        # For now, we simulate a successful upload
        print(f"Uploading file to: {s3_key}")
        return True

    def generate_presigned_url(self, s3_key):
        # Generates a temporary link
        return f"https://s3.amazonaws.com/my-bucket/{s3_key}?token=secret"

class S3Client:
    def upload_file(self, file_data, s3_key):
        # In a real app, this sends data to Amazon
        # For now, we simulate a successful upload
        print(f"Uploading file to: {s3_key}")
        return True

    def generate_presigned_url(self, s3_key):
        # Generates a temporary link
        return f"https://s3.amazonaws.com/my-bucket/{s3_key}?token=secret"

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.

Step 4: The Attachment Service (Integration)

Now we create a service that brings the database repository and cloud storage together. Notice how db_repo.create() matches exactly the method we defined in Step 2.

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
        s3_key = f"tasks/{task_id}/{filename}"
        self.s3_client.upload_file(file_data, s3_key)

        # 2. Save metadata to database
        return self.db_repo.create(
            task_id=task_id,
            filename=filename,
            file_size=len(file_data),
            s3_key=s3_key
        )

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
        s3_key = f"tasks/{task_id}/{filename}"
        self.s3_client.upload_file(file_data, s3_key)

        # 2. Save metadata to database
        return self.db_repo.create(
            task_id=task_id,
            filename=filename,
            file_size=len(file_data),
            s3_key=s3_key
        )

By passing db_repo and s3_client into the service we allow it to use both tools to complete the upload. This is the Dependency Injection pattern from CODEX.md.

text

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

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

Generating the Phased Technical Plan

Join the 1M+ learners on CodeSignal

Mapping Dependencies and Parallel Paths

Executing the 13-Task Workflow

Summary and Next Steps