Scaling Video Production: Managing State and Concurrency

AtlasRepo Videos
, , , ,
1

A diagram showing a single master video template connecting to multiple client data records, which then feed into a concurrent rendering pipeline producing various aspect ratios.
A diagram showing a single master video template connecting to multiple client data records, which then feed into a concurrent rendering pipeline producing various aspect ratios.1200×1200 65.5 KB

Automating video production for multiple clients introduces challenges in state management and error handling. How are you tracking render IDs and ensuring that failures in one client’s pipeline do not impact others? Share your strategies for managing concurrent renders and maintaining data integrity.

Original source

A guide to automating video content production for multiple clients — Shotstack

What the source supports

The source provides a technical guide on automating video production for multiple clients using a single master template and merge fields. It covers creating templates, managing client data, handling concurrent renders, and storing render IDs in a local database. It also discusses best practices for assets, error handling, and dynamic aspect ratios.

What AtlasRepo adds

AtlasRepo synthesizes the source’s technical steps into a broader architectural discussion, emphasizing the importance of state management, error isolation, and scalable design patterns. It adds context on why certain approaches, like using merge fields for dimensions, are preferred and highlights the limitations of the API, such as the lack of a render list endpoint.

Key takeaways

  • Use a single master template with merge fields to handle multiple clients, avoiding the need for separate templates per brand.
  • Store render IDs in your own database immediately upon submission, as the API does not provide a list of all renders.
  • Utilize explicit width and height merge fields rather than aspect ratio enums to support dynamic output dimensions.
  • Implement concurrent rendering with error isolation (e.g., Promise.allSettled) to ensure one failure doesn’t halt the entire batch.
  • Use inline SVG for brand marks to avoid hosting overhead, ensuring proper XML namespaces are included.
  • Treat brand kits as local database records that expand into merge fields at render time, not as platform-specific features.

Questions for the community

  1. What database schema do you use to link render IDs with client data and track render status?
  2. How do you handle errors in concurrent rendering batches to ensure maximum throughput?
  3. What are your experiences with using inline SVGs for brand marks in automated video templates?