About This Unit's Practice Environment:

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

Important: Simplified Practice Environment

The practices in this unit use simplified, mocked components designed for the CodeSignal learning environment:

• Mock S3 storage (dictionary-based, no real AWS)
• Simple Python classes (not full FastAPI production code)
• Basic database simulation (no real transactions)
• Mocked virus scanner (keyword checking, not real ClamAV)

Why this approach?

Complex production systems (real S3, Redis, PostgreSQL) can't run in browser-based learning environments. The decomposition methodology you're learning—breaking features into phases, identifying dependencies, enabling parallel work—is identical whether you're mocking services or using production infrastructure.

Your real-world application:

After this course, you'll apply these same decomposition patterns to production stacks (FastAPI + Postgres + AWS, Django + MySQL + GCP, Express + MongoDB, etc.). The thinking process is what matters, not the specific libraries.

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:

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.

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.

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 and the correctly.

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 Claude) to finish work faster.

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.

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.

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.

In this lesson, you have learned how to:

1. Analyze Multi-Component Requirements: Move beyond local database changes to coordinate with external systems (or mocked versions for learning).
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 (real or mocked).

What you're taking to production:

• The 5-phase decomposition pattern (Foundation → Storage → Validation → API → Testing)
• Dependency mapping techniques to identify parallel work
• Integration patterns for coordinating multiple components
• Rollback strategies for handling failures

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