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:

  1. Store the actual file in a cloud storage bucket (like Amazon S3).
  2. Save the metadata (the file's name, size, and type) in our database.
  3. Check the file for viruses and size limits before saving it.
  4. 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 focused and ensures that the foundation of the system is solid before we build the complex 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.

ComponentResponsibilityExample
DatabaseStores information about the file.File name: contract.pdf, Size: 2MB
S3 StorageStores the actual file data.A file located at /attachments/task-123/contract.pdf
ValidatorsChecks 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.

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.
Mapping Dependencies and Parallel Paths

In a complex 13-task project, some tasks depend on others. This is called the Critical Path. For example, you cannot build the Upload API if the Attachment Database Model doesn't exist yet.

However, many tasks are independent. We call these Parallel Opportunities. Identifying these allows a team (or you, working with Codex) to finish work faster.

Task IDComponentPhaseDependenciesCan run in parallel?
T001Attachment Model1NoneNo (Start here)
T003S3Client2NoneYes (With Phase 1)
T005MIME Validator3NoneYes (With Phase 2)
T008Attachment Service
Executing the 13-Task Workflow

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.

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.

Summary and Next Steps

In this lesson, you have learned how to:

  1. Analyze Multi-Component Requirements: Move beyond local database changes to coordinate with external systems.
  2. Implement Phased Decomposition: Group tasks into logical phases to maintain AI focus.
  3. Identify Parallel Opportunities: Recognize tasks that can be developed concurrently to optimize workflow.
  4. Execute Integration Patterns: Use Dependency Injection to connect databases with cloud storage services.

You are now ready to apply these concepts in the practice exercises. You will use the CodeSignal IDE and Codex to build the Task Attachment system yourself, starting from a technical plan and moving through the phases of execution.

Sign up
Join the 1M+ learners on CodeSignal
Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal