Research task (Technical Documentation):
Write a technical proposal for a distributed audio streaming system. The system should include an audio streaming platform and a live chat feature. This application should be built for both browser and mobile settings. Include detailed technologies and justify why they are used. Assume the audience is a team of experienced software developers at a medium sized software company.

Evaluation rubric:
criterion: The response is organized into sections with labels that clearly convey the main idea of its body (e.g., "Introduction" providing an overview, "System Architecture" detailing the high-level design, "Technology Stack" justifying specific choices, "Audio Pipeline," "Chat Subsystem," "Scalability and Performance," "Security Plan," "Deployment and DevOps," "Project Timeline," and "Cost Analysis").
weight: 3
axis: Communication Quality

criterion: The response suggests a reasonable platform for hosting the infrastructure (e.g., Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Cloudflare) and lists a relevant technology stack for that platform (e.g., if AWS is chosen, suggests Amazon S3 for storing audio files and artwork, Amazon ECS or Fargate for hosting the API, Amazon DynamoDB for tracking the content catalog and user profiles, and Amazon OpenSearch Service for full-text search and chat cataloguing).
weight: 5
axis: Explicit Criteria

criterion: The response includes at least one system architecture diagram or flowchart to demonstrate how the components (e.g., client applications, load balancers, API gateway, microservices, databases, CDN, and chat servers) interact with each other.
weight: 3
axis: Communication Quality

criterion: The response includes a discussion of scenarios related to budgeting (e.g., a cost-breakdown for high/standard/low usage, a forecast for near and long-term maintenance, the expected cost to accommodate customer growth, and costs associated with human labor).
weight: 4
axis: Implicit Criteria

criterion: The response discusses plans to handle spikes in user streaming traffic (e.g., caching media segment data to reduce origin load, using multiple Content Delivery Networks (CDNs) to spread traffic and fail over, setting rate limiting and throttling on APIs to protect backends, and monitoring real-life traffic to preempt spikes).
weight: 4
axis: Implicit Criteria

criterion: The response mentions at least one similar product existing on the market in the audio streaming space (e.g., Clubhouse for live audio, Spotify Live for interactive sessions, Twitter Spaces as a platform's built-in feature, or Discord for real-time voice chat).
weight: 3
axis: Implicit Criteria

criterion: The response proposes a timeline for deliverables with key milestones (e.g., Phase 1: Core API & Audio Pipeline, Phase 2: Chat Subsystem & Mobile App, Phase 3: Web App & Scalability Testing) and provides a justification for its feasibility given a team of experienced software engineers.
weight: 3
axis: Implicit Criteria

criterion: The response includes details to maintain the system, e.g., logging artifacts (e.g., capturing service-level API calls and chat messages, logging errors with stack traces and IDs, including relevant metadata, cache hit/miss events), monitoring performance metrics (e.g., tracking infrastructure-level metrics like CPU/memory, application KPIs like stream latency and buffering ratio, using distributed tracing, database performance), tracking analytics (e.g., number of concurrent listeners, chat participation rates, feature adoption, anomaly occurrence), and security monitoring (e.g., failed logins, suspicious IP patterns, admin actions, patch application).
weight: 5
axis: Explicit Criteria

criterion: The response includes a plan for scaling the system to a large number of users, e.g., traffic distribution and edge delivery (e.g., CDN offloading, load balancers, fan-out services), data and state scaling (e.g., database sharding, distributed caching, externalized state), asynchronous workflows (e.g., event streaming, message queues, CQRS), and autoscaling/resilience (e.g., Kubernetes HPA/KEDA, resilience patterns like circuit breakers, multi-region failover).
weight: 5
axis: Explicit Criteria

criterion: The response includes an outline or plan for DevOps, e.g., continuous integration and deployment pipelines (e.g., GitHub Actions, GitLab CI), infrastructure automation (e.g., Terraform, Ansible), monitoring and observability (e.g., Prometheus/Grafana, ELK stack), and automated testing (e.g., unit/integration test suites, load testing tools).
weight: 5
axis: Explicit Criteria

criterion: The response suggests at least one Application Programming Interface (API) style (e.g., REST for integration, gRPC for high-performance internal services, GraphQL for mobile queries, WebSockets for live chat) and discusses factors for designing a well-defined API, including specific endpoint examples (e.g., 'POST /v1/auth/login', 'POST /v1/streams', 'POST /v1/streams/{id}/chat/messages', 'GET /v1/admin/health').
weight: 5
axis: Explicit Criteria

criterion: The response discusses a plan to implement security features relevant to the streaming system, e.g., data encryption (e.g., in transit via TLS, at rest for audio files), access control (e.g., public, authenticated, and admin endpoints), key/credential management (e.g., automatic key rotation, secrets in a vault service, short-lived tokens), and threat protection (e.g., rate limiting, Web Application Firewall (WAF), bot prevention).
weight: 4
axis: Explicit Criteria

criterion: The response compares various audio-streaming protocols and suggests one (e.g., HLS for its native iOS support and scalability, DASH as an open standard, or WebRTC for ultra-low latency) and justifies the choice.
weight: 5
axis: Explicit Criteria

criterion: The response discusses relevant components of audio delivery and processing, e.g., identifying suitable audio codecs (e.g., Opus, AAC), media servers (e.g., Wowza Streaming Engine, Janus WebRTC Server), and a content delivery/caching strategy (e.g., Cloudflare CDN, Amazon CloudFront, Akamai).
weight: 5
axis: Explicit Criteria

criterion: The response discusses tangible performance goals for the system (e.g., audio latency < 1 second, chat message-to-live time < 500ms, total system uptime of 99.95%, concurrent user capacity, bandwidth efficiency).
weight: 4
axis: Implicit Criteria

criterion: The response discusses the tech stack for both the mobile and web interface, e.g., cross-platform frameworks (e.g., React Native + Expo, Flutter, web-based React, Capacitor), UI/UX factors (e.g., responsive layouts, chat UI/UX consistency, accessibility, background audio behavior), and performance/networking (e.g., service workers for caching, efficient state management).
weight: 5
axis: Explicit Criteria

criterion: The response proposes technologies without justification for their relevance to the streaming system in terms of cost or performance.
weight: -5
axis: Explicit Criteria

criterion: The response suggests a project delivery model and justifies this option with respect to an experienced team (e.g., Agile/Scrum for its iterative approach and adaptability, or a hybrid model).
weight: 3
axis: Implicit Criteria

criterion: The response discusses relevant legal and regulatory requirements (e.g., data protection and privacy compliance like GDPR or CCPA, copyright/licensing for streamed content, and content moderation policies for chat).
weight: 3
axis: Implicit Criteria

criterion: The response mentions technologies that are not relevant to the audio streaming or chat system without justification (e.g., video streaming codecs, game engines, or blockchain technologies).
weight: -5
axis: Explicit Criteria

criterion: The response clearly states its assumptions about the composition of the development team (e.g., team size, experience levels, skill specialization like backend/frontend/mobile/DevOps, and availability of supporting roles).
weight: 3
axis: Implicit Criteria