Part 3: System Design & Architecture Planning

When I built shotsrv, my solo project for taking screenshots of URLs, I didn’t think much about system design. I spun up a single server, installed PhantomJS, and called it a day. If the server crashed, I’d restart it. If traffic spiked, I’d cross my fingers and hope for the best.

But when you’re building something like FamFlix, a Netflix-like platform for families to share private videos, that “just wing it” approach won’t cut it. Why? Because system design isn’t just about making things work. It’s about making things work for everyone, even when 10,000 families are uploading and streaming videos at the same time.

In this article, we’ll explore how to turn requirements into a scalable, secure architecture, and how stakeholders collaborate to make it happen.

The Stakeholders in System Design

System design isn’t just a developer’s job. It’s a team effort that involves:

1. Backend Engineers: Design APIs, databases, and microservices.
2. DevOps Engineers: Plan infrastructure, CI/CD pipelines, and monitoring.
3. Security Experts: Ensure data encryption, access controls, and compliance.
4. Product Managers: Prioritize features and balance technical debt.
5. UX Designers: Advocate for performance and usability.

Each stakeholder brings a unique perspective, ensuring the system is robust, scalable, and user-friendly.

How to Measure Completion

In system design, “done” doesn’t mean “it works on my machine.” It means:

1. Backend Engineers: APIs are documented, databases are normalized, and microservices are containerized.
2. DevOps Engineers: Infrastructure is provisioned, CI/CD pipelines are automated, and monitoring is in place.
3. Security Experts: Data is encrypted, access controls are tested, and compliance audits are passed.
4. Product Managers: Features are prioritized, technical debt is tracked, and stakeholders are aligned.
5. UX Designers: Performance benchmarks meet user expectations (e.g., <2s load time).

These metrics ensure everyone knows when their work is complete, and when it’s time to move on to the next phase.

Step 1: Define the High-Level Architecture

The first step in system design is to create a high-level architecture diagram. For FamFlix, this might include:

• Frontend: A React.js app for browsing and streaming videos.
• Backend: Node.js APIs for video upload, processing, and metadata management.
• Storage: AWS S3 for video files, with lifecycle policies for cost optimization.
• CDN: CloudFront for fast, global video delivery.
• Database: MySQL for metadata (e.g., video titles, user comments).

This diagram serves as a shared vision for the team, ensuring everyone understands how the pieces fit together.

Step 2: Break Down the Components

Next, we break the architecture into smaller components, each with clear ownership. For example:

1. Video Upload Service:
   • Owner: Backend Engineer
   • Requirements: Handle 1GB uploads, validate file types, trigger transcoding.
   • Completion Criteria: API documented, load-tested for 1,000 concurrent uploads.
2. Transcoding Service:
   • Owner: Backend Engineer
   • Requirements: Convert videos into 480p, 720p, and 1080p using FFmpeg.
   • Completion Criteria: Transcoding completes within 5 minutes for a 1GB video.
3. Storage Layer:
   • Owner: DevOps Engineer
   • Requirements: Store raw and processed videos in S3, with lifecycle policies.
   • Completion Criteria: Videos are accessible within 100ms, costs are within budget.
4. Streaming Service:
   • Owner: Backend Engineer
   • Requirements: Deliver videos via HLS or MPEG-DASH for adaptive streaming.
   • Completion Criteria: Videos stream without buffering on 90% of devices.
5. Security Layer:
   • Owner: Security Expert
   • Requirements: Encrypt videos at rest and in transit, implement OAuth2 for authentication.
   • Completion Criteria: Penetration tests pass, GDPR compliance confirmed.

Step 3: Plan for Scalability and Resilience

A good system design doesn’t just work, it works under pressure. For FamFlix, this means:

• Scalability: Use auto-scaling groups to handle traffic spikes (e.g., holiday video uploads).
• Resilience: Implement retries, fallbacks, and circuit breakers to handle failures gracefully.
• Monitoring: Set up CloudWatch or Prometheus to track performance and alert on issues.

For example, if the transcoding service fails, the system should retry twice, then notify the user. Not crash the entire platform.

You might have seen several service crash on their first day of launch. This occurs when the team doesn't take scalability into account early one.

Step 4: Validate the Design

Before writing a single line of code, the team should validate the design through:

1. Peer Reviews: Engineers critique each other’s designs for gaps or inefficiencies.
2. Stakeholder Sign-Off: Product managers, designers, and security experts confirm the design meets requirements.
3. Prototyping: Build a small-scale version of the system to test key assumptions (e.g., transcoding latency).

This process ensures the design is both technically sound and aligned with stakeholder expectations.

---

Why This Process Matters

System design is where the rubber meets the road. It’s where vague requirements become concrete plans, and where individual contributions come together to form a cohesive whole. By involving all stakeholders and measuring completion rigorously, we ensure FamFlix isn’t just a collection of features. It’s a platform families can rely on.

Coming Up Next…

In Part 4, we’ll dive into Prototype Development & Validation: how to build a small-scale version of FamFlix to test key assumptions and gather feedback.

In the meantime, ask yourself: If I designed FamFlix alone, what scalability or security risks would I overlook? And how would that hurt real users?

---