Techlist.io - Korean Tech Blog Curator

meta3 min readCurated summary

Adopting AV1 for Real-Time Communication (RTC) at Scale

Meta’s adoption of AV1 for real-time communication has been a multi-year effort focused on codec efficiency, device compatibility, latency, power consumption, and resilience to poor networks. AV1 can reduce bitrate by at least 20% versus H.264/AVC while preserving quality, especially below 100 kbps and for screen content. However, making it practical for mobile video calls required low-complexity encoding, careful decoder selection, and systems designed to avoid freezes caused by bitrate spikes and packet loss. ## Why Meta Adopted AV1 for RTC - AV1 delivers comparable visual quality at substantially lower bitrates than H.264/AVC. - Offline testing showed at least a 20% bitrate reduction on low-end and mid-range devices under Meta’s product settings. - Lower bitrate is especially valuable in real-time calls, where network rates may fluctuate between 10 and 400 kbps. - At a 100 kbps limit, AV1 video remained much clearer than H.264/AVC, which appeared blurry. - AV1 is also well suited to screen sharing: - **Palette mode** efficiently represents frames with a limited number of colors. - **Intra-block copy** predicts repeated patterns within the same frame. - Both tools improve the readability of text and other computer-generated content. ## Challenges of Real-Time Video - RTC requires end-to-end latency below roughly 300 milliseconds; techniques common in video-on-demand, such as multi-pass encoding and extensive buffering, can introduce unacceptable delay. - Sudden bitrate increases can cause freezes. - Network bandwidth changes may require adjustments to resolution or frame rate. - Resolution changes generally require a key frame, producing a temporary bitrate spike. - Packet loss can trigger retransmissions or additional key frames, also increasing the risk of freezes. - Mobile devices must encode and decode video simultaneously, making power efficiency essential. ## Encoder Selection and Complexity - AV1’s advanced coding tools improve compression but can significantly increase encoding complexity. - An open-source AV1 encoder consumed 14% more power than H.264/AVC on a Pixel 8 during testing. - AV1 also used more memory, contributing to application crash regressions. - Meta therefore adopted an internal low-complexity AV1 encoder with power consumption comparable to H.264 baseline. - The encoder supports multiple presets: - Higher-complexity presets prioritize quality. - An ultra-low-complexity preset offers complexity comparable to H.264/AVC. - Meta selects the encoder preset according to device capabilities, allowing AV1 deployment beyond high-end phones. ## Decoder Selection - Although decoding is generally less demanding than encoding, AV1 decoding was still challenging for low-end mobile devices. - Initial tests found real-time decoding failures, video freezes, and audio/video synchronization problems on some devices. - Meta evaluated multiple open-source decoders and selected **dav1d** based on its power efficiency and reliability. Meta’s experience shows that AV1 adoption in RTC requires more than simply enabling a new codec. A practical deployment depends on device-specific complexity controls, efficient decoding, strict latency management, and mechanisms that prevent bandwidth changes or packet loss from interrupting calls.

Read original(opens in new tab)
aws4 min readCurated summary

AWS Weekly Roundup: NY Summit recap, Local Zone in Hanoi, Grok 4.3 in Bedrock, price reductions, and more (June 22, 2026) | Amazon Web Services

AWS’s June 22, 2026 roundup centers on the New York Summit’s focus on AI agents that continuously create value across work, security, software development, and customer applications. It also highlights new regional infrastructure, developer tools, Bedrock models, data capabilities, performance improvements, and several price reductions. Overall, AWS is emphasizing agent-driven automation while lowering barriers and costs for building and operating cloud workloads. ## New York Summit: Agents Across the AWS Stack - **Agents for working:** Amazon Quick supports autonomous, multi-step agents and provides a prioritized activity feed combining email, Slack, calendars, and tasks. - **Agents for securing:** AWS Continuum is an AI-native security service designed to reason about, validate, and remediate vulnerabilities across the development lifecycle. - AWS Security Agent adds threat modeling, pull-request scanning and remediation, and IDE integrations through Kiro, Claude Code, and MCP. - **Agents for building:** Kiro, AWS DevOps Agent, and AWS Transform support continuous coding, deployment, release assessment, and autonomous modernization. - Kiro now includes a native iOS app. - AWS DevOps Agent can evaluate code changes before production release. - **Agents customers create:** Amazon Bedrock AgentCore adds a generally available infrastructure and orchestration harness, Web Search, Managed Knowledge Base, Guardrails integrations, and AWS Context for mapping organizational data relationships. ## New Infrastructure and Developer Services - **AWS Local Zone in Hanoi:** The new `ap-southeast-1-han-1a` zone supports Amazon S3 and Amazon EBS Local Snapshots, helping customers satisfy local data residency and backup requirements. - **AWS Blocks:** This preview open-source TypeScript framework provides a local environment with Postgres, authentication, and real-time messaging without requiring an AWS account. Applications can later deploy to AWS without code changes, with optional CDK integration. - **AWS Management Console Private Access:** Enterprises can access the AWS Console from isolated VPCs without internet connectivity, supporting air-gapped security models. - **AWS Marketplace Storefront:** Partners can publish branded catalogs of AWS Marketplace solutions on their own websites or applications. ## AI, Data, and Agent Capabilities - **Grok 4.3 in Amazon Bedrock:** xAI’s model is available for reasoning, agentic, and enterprise workflows, with tool calling, structured output, and response streaming. - **Amazon S3 annotations:** Objects can now carry up to 1 GB of mutable, queryable context, reducing the need for separate metadata systems in AI-agent and autonomous workflows. - **Strands Agents:** The open-source toolkit adds improved Harness SDK context management, isolated execution through Strands Shell, and chaos testing and red-team capabilities in Strands Evals. - **NVIDIA-powered EC2 G7:** G7 instances use NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs and sixth-generation Intel Xeon processors, delivering up to 4.6 times the AI inference performance and 2.1 times the graphics performance of G6 instances. ## Performance and Security Improvements - **Faster Amazon ECS auto scaling:** Support for 20-second metrics reduces scale-out trigger time from 363 to 86 seconds and total scaling and task provisioning time from 386 to 109 seconds in AWS benchmarks. - **Palo Alto Networks DNS Security:** Route 53 Resolver DNS Firewall can apply PANW Advanced DNS Security protections directly, without separate firewalls or VPC changes. ## Price Reductions - **Amazon S3 Vectors:** Query charges for large vector indexes fall by up to 80%, with no application changes required. - **Amazon GameLift Servers:** Generation 6 and newer instances now include free inbound and outbound network bandwidth for both On-Demand and Spot usage. - **AWS Marketplace professional services:** Listing fees drop from 2.5% to 0.5%, reducing transaction costs for consulting, managed services, and software partners. AWS’s latest direction is to combine increasingly autonomous agents with faster infrastructure, broader model choice, stronger security, and lower operating costs. Developers and organizations should evaluate Bedrock AgentCore, AWS Blocks, S3 annotations, and the new regional and private-access options where they can simplify agent development or satisfy data and security requirements.

Read original(opens in new tab)
naver1 min readCurated summary

Building an Integrated Context Provider for Humans and AI Agents

The content is a minimal NAVER D2 page rather than a substantive technical blog post. It includes a “Hello world” entry and navigation links to D2 News, About D2, NAVER Developers, DEVIEW, OpenSource, and D2 STARTUP FACTORY. No technical argument, explanation, or conclusion is provided. ### Page Navigation - D2 News - About D2 - NAVER Developers - DEVIEW - OpenSource - D2 STARTUP FACTORY ### Footer - Copyright © NAVER Corp. All Rights Reserved. No practical technical recommendation can be derived from the provided content.

Read original(opens in new tab)
line4 min readCurated summary

Unifying Analysis Through the Power of Analytics Agents: Work Innovation and Role Transformation in the Generative AI Era at a Professional Organization

PJ One Piece is LY Corporation’s initiative to connect business questions, data analysis, insight generation, and next-action planning through generative AI. Its analysis agent reduced typical turnaround times from about two weeks to roughly 10 minutes, enabling hundreds of analyses each month and adoption by more than half of an early-adopter business unit. The project treats AI not as a chat interface, but as an analysis platform that connects data, knowledge, people, and organizational processes. ## Three Disconnects Behind the Project - **Business and data:** Even with a data warehouse and BI tools, business users still needed to understand SQL, tables, column definitions, KPI rules, and result interpretation. - **Within the analysis process:** Task definition, analysis design, execution, review, and action planning were often handled by different people or tools, causing context loss, rework, delays, and inconsistent quality. - **Across domains:** Useful analysis patterns and domain knowledge remained isolated because services used different KPIs, table structures, business assumptions, and review criteria. ## The Analysis Agent as a Connector - Users ask questions in natural language without needing to know SQL or database structures. - The agent: - Clarifies the business objective and missing assumptions. - Finds relevant data and creates an analysis plan. - Executes queries and specialized analyses. - Interprets results and produces visualizations or reports. - Suggests further analysis and possible next actions. - The platform consists of: - A user-facing application. - An LLM-based agent for reasoning and tool use. - Tools for SQL, Python, document search, and visualization. - A knowledge base containing domain information, skills, and table metadata. - Logging, feedback, monitoring, and evaluation systems. - Domain knowledge is added through a plugin-like structure, while logs and feedback continuously improve the system. ## Turning Business Questions into Analysis Requirements - Natural-language questions often leave important assumptions unspecified, such as: - Target population or campaign definition. - Analysis period and comparison group. - KPI definitions. - Aggregation level. - Exclusion conditions. - Rather than requiring users to write detailed prompts, the agent uses domain knowledge to determine what can be inferred and asks only about unresolved points. - Knowledge bases document service context, KPI definitions, aggregation cautions, policy information, and review requirements. - Table metadata explains available tables, columns, appropriate use cases, samples, partition requirements, and usage restrictions. ## Reaching Data Safely and Reliably - Table metadata is revealed progressively: - The agent first narrows down relevant tables. - It then retrieves detailed definitions and usage rules only for those tables. - Analysis-oriented wide tables or logical views combine transaction data with commonly needed attributes, reducing complicated joins and SQL-generation errors. - SQL is checked before and after execution to enforce: - `SELECT`-only access. - Approved tables and usage rules. - Required partition conditions. - Restrictions on sensitive or personal data. - Result-size limits. - These guardrails allow the agent to perform analysis flexibly without exposing data or infrastructure to unnecessary risks. ## Preserving Context Across the Analysis Process - PJ One Piece uses a supervisor-style multi-agent architecture. - A main agent maintains: - The user’s request and business objective. - The current analysis plan. - Findings and constraints discovered so far. - Remaining questions and decision points. - Specialized sub-agents handle tasks such as statistical testing, time-series analysis, clustering, and independent review. - This separates complex or specialized work from the main context while preserving overall continuity. - Progress updates expose discoveries, design decisions, data limitations, and constraints so users can adjust direction during longer analyses. ## Building Reusable Organizational Capability - Logs record agent actions, assumption checks, analysis designs, generated SQL, errors, and outputs. - User and analyst feedback helps identify whether improvements are needed in prompts, tools, data, or reusable skills. - Repeated workflows are formalized as skills, including: - General-purpose methods such as time-series and clustering analysis. - Domain-specific workflows such as monthly reporting or policy monitoring. - Skills document required assumptions, comparison axes, cautions, and interpretation methods. - Over time, isolated domain knowledge becomes reusable organizational analysis capability. ## Business Impact - In early deployment, the platform expanded data use beyond data scientists to product owners and frontline employees. - More than half of the participating business unit’s members use it. - Analysis turnaround fell from an average of approximately two weeks to about 10 minutes. - The platform now supports hundreds of analyses per month and serves as a daily starting point for business questions. PJ One Piece’s main recommendation is to design AI analysis as an end-to-end operating platform—not merely an automated SQL or chatbot tool. Combining structured domain knowledge, safe data access, contextual multi-agent workflows, reusable skills, and continuous evaluation can make analysis faster while steadily improving its quality and organizational reach.

Read original(opens in new tab)
line4 min readCurated summary

From Automation to AI with Infrastructure as Code (IaC): Adopting OpenTofu and ChatOps

LY Corporation’s LINE Plus SRE team migrated Verda cloud infrastructure and IMON monitoring resources from scattered, manual management into an Infrastructure as Code (IaC) and GitOps workflow. Using OpenTofu and Terragrunt, they now manage roughly 1,500 resources across seven services through pull requests, CI/CD, and daily drift detection. The migration required careful automation for importing existing resources, normalizing state, and handling provider limitations and resource dependencies. ## Why IaC Was Needed - Teams previously managed infrastructure through different methods: - Verda’s web dashboard - Scripts - Wiki-based procedures - Personal documents and GitHub repositories - As the number of services and resources grew, this caused: - Inconsistent management practices - Difficult-to-track configuration changes - Greater risk of manual errors - Poor reproducibility and reviewability - The team adopted GitOps so that: - Desired infrastructure state is declared in Git. - All changes go through pull requests. - Infrastructure history is versioned and auditable. - CI/CD applies approved changes automatically. - Their goal was to manage infrastructure with the same engineering standards as application code: reviewable, version-controlled, and reproducible. ## Choosing OpenTofu and Terragrunt - OpenTofu was selected as an open-source Terraform fork. - It retains: - Terraform’s HCL syntax - Provider compatibility - Familiar module and configuration patterns - The team created reusable modules for: - Virtual machines - Load balancers - Monitoring alerts - Modules were versioned so updates could be adopted explicitly rather than affecting every environment immediately. - Terragrunt was added to reduce repetition in environment configuration. - Shared settings are defined once in a parent `root.hcl`. - Individual environments contain only their differing inputs. - OpenTofu reduces duplication in resource definitions, while Terragrunt reduces duplication in environment and backend configuration. ## Planning the Migration - The most difficult part of introducing IaC into an existing environment was importing resources that were already running. - Manual import was considered impractical for hundreds of VMs, load balancers, and DNS records because it would be slow and error-prone. - The migration was split into two phases: - **Phase one:** Automate imports, select one service for a pilot, and establish the complete OpenTofu/Terragrunt pipeline. - **Phase two:** Reuse the validated modules and import scripts to roll the approach out to the remaining services. ## Designing the Import Process - Import scripts were designed to: - Query existing resources - Decide which resources should be managed by IaC - Convert resource data into the desired code structure - Generate Terragrunt configuration - Connect resources to OpenTofu state - Run `plan` to verify that no unintended changes would occur - A key requirement was keeping three representations aligned: - Configuration code - OpenTofu state - Actual cloud resources - Normalization was added because equivalent values could be represented differently—for example, network or image IDs—causing OpenTofu to report misleading differences after import. ## Resource-Specific Import Strategies - Resources could not all be imported using the same procedure. - Different resource types have different identifiers, dependencies, and ownership models: - **VMs:** Imported individually, while distinguishing manually created instances from Kubernetes-managed instances. - **Load balancers:** Imported together with related listeners and pools. - **DNS:** Imported while preserving zone and record relationships. - **Kubernetes:** Structured around clusters and node pools. - **IMON:** Imported according to its hierarchy of teams, alert groups, alert rules, and monitors. - Each resource followed the same broad five-step process, but its implementation was adapted to the resource’s characteristics. ## Problems Discovered During Migration ### Kubernetes-Managed VMs - OpenStack contained both manually created VMs and VMs automatically created by Kubernetes. - Importing Kubernetes-managed VMs into IaC could cause conflicts between OpenTofu and Kubernetes. - The scripts excluded these VMs using naming patterns and metadata. ### IMON’s Hierarchical Structure - IMON alerts are organized as: `Team → Alert Group → Alert Rule → Monitor` - A flat import would lose these relationships. - The team mirrored the hierarchy in the directory structure so ownership and relationships were visible from the file layout. ### Provider and Regional Identifier Issues - The actual cloud platform allowed both hyphens and underscores in load balancer names, but the provider validation logic rejected underscores. - The team fixed this by modifying the provider’s validation logic and contributing the change upstream. - Resource UUIDs such as `flavor_id`, `image_id`, and `network_id` differed by region. - This produced unnecessary changes in `plan`. - The modules added regional mapping logic, allowing users to specify readable names while resolving them to region-specific IDs. The migration demonstrates that successful IaC adoption requires more than writing configuration files: existing infrastructure must be filtered, normalized, modeled according to its dependencies, and validated against real provider behavior. OpenTofu and Terragrunt provided the foundation for scalable GitOps management, while custom import automation and provider improvements made the transition safe for production resources.

Read original(opens in new tab)
toss3 min readCurated summary

Why Does Our Team’s Documentation Fail? (2)

Documentation succeeds not through individual resolve, but through centralized knowledge, clear purpose, and systems that reduce the fear of being wrong. Interviews across a commerce domain and a server-development chapter show that documentation strategies must match an organization’s existing maturity, audience, and work patterns. AI lowers the cost of writing and sharing knowledge, while also requiring more deliberate document organization. ## Lessons from Early Attempts - The commerce wiki was initially designed as a self-service platform supported by workshops and guilds. - Workshops could encourage a first contribution, but sustaining second, third, and later contributions was difficult. - In the Ads domain, documentation was already strong, so the better approach was to respect existing conventions and help people locate knowledge rather than create another system. - Organizations with little documentation need to build foundational knowledge; organizations with mature documentation need better discovery and maintenance. ## Reducing the Fear of Asking and Writing - Developers often avoid asking questions because doing so publicly reveals what they do not know. - They may also hesitate to publish documentation because they fear their knowledge could be inaccurate. - The team addresses this through: - **“Lee’s Development Consultation Week,”** which normalizes questions and encourages teammates to answer questions Lee cannot address. - **A daily knowledge bot, “Ha,”** which shares short server-development tips automatically. - Correcting or adding to an existing shared post feels easier than writing a complete document from scratch. ## How AI Has Changed Documentation - AI makes it faster to create initial drafts and distribute knowledge through chatbots. - It also enables measurement of knowledge flow, including: - The number of questions asked. - Whether teammates provide answers. - The quality and content of those answers. - The number of new documents and week-over-week growth. - These metrics reveal knowledge gaps and recurring questions without manually reviewing every channel. - AI also creates a need for more detailed internal context than human readers typically require. - Commerce therefore separates: - Central, human-friendly documentation managed by technical writers. - Team-repository documentation containing detailed, team-specific context useful to AI but unnecessary for everyone else. ## Shared Principles and Organizational Differences - Both domains and chapters should centralize knowledge and avoid spreading it across too many channels. - Domains typically: - Connect documentation to products and code. - Change rapidly. - Serve a broad and varied audience. - Chapters typically: - Document conventions, working methods, and professional knowledge. - Change more slowly. - Focus on productivity and capability development. - Have a clearer audience, such as a specific role or discipline. - Domain documentation should be understandable even to non-developers, since developers may also lack context outside their specialties. - Separating guides, capability-based policies, glossaries, and metrics helps different readers find documents suited to their needs. ## Where to Begin - First diagnose the organization’s current documentation maturity by asking what people do when they get stuck: - **Ask coworkers or search chat:** foundational documentation is largely missing. - **Search documents:** assess whether information is easy to find; fill gaps if searches fail. - **Ask an AI or bot:** evaluate whether answers are accurate and whether the underlying documents are complete, current, centralized, and sufficiently contextualized. - Define the specific problem driving documentation, rather than starting with a vague goal. - Begin with a focused need, such as creating a glossary for inconsistent terminology or building references for sharing knowledge with other teams. The practical recommendation is to centralize knowledge, identify the organization’s biggest documentation gap, and build a low-friction system where people can contribute, correct, and consume information without relying solely on personal effort.

Read original(opens in new tab)
toss3 min readCurated summary

es-toolkit: How an Internal Little Library Became a Global Library

es-toolkit began as Toss’s effort to create a modern alternative to lodash, removing legacy code and optimizing for current JavaScript environments. By focusing on common use cases, it achieved 2–10× faster performance and reductions in bundle size of more than 30×. Community adoption, compatibility tooling, and contributions to major projects eventually pushed it beyond 20 million weekly npm downloads. ## Why es-toolkit Was Created - Developers frequently needed utilities such as `throttle`, `debounce`, and `uniq`, but existing options had drawbacks. - lodash contained legacy implementations, Internet Explorer workarounds, and limited ECMAScript Modules support. - Even `lodash-es` mainly added ESM support without modernizing the underlying code. - Toss had maintained its own `@toss/utils`, but handling utility-function edge cases internally was burdensome. - es-toolkit’s goal was to remove unnecessary logic, improve performance, and produce smaller bundles for modern web applications. ## Performance and Bundle-Size Improvements - Reimplementing core lodash-style functions produced: - At least 2× faster execution for some functions. - More than 10× faster execution for others. - Using modern built-ins such as `Array#map` eliminated compatibility code. - Bundle sizes were reduced by more than 30× in some cases. - The project was designed around the most common use cases rather than every historical edge case supported by lodash. ## Growth Through the Open-Source Community - The first release was shared through Toss’s frontend social channels and quickly attracted users and contributors. - Contributors added missing functions, fixed bugs, and optimized implementations. - After promotion on international developer communities, the project received more than 100 recommendations and tens of thousands of repository visitors. - Blogs and newsletters helped extend its reach. - Community members created migration plugins and independently replaced lodash dependencies in other libraries. ## From Contributor to Maintainer - Toss Bank developer Dayong first joined as an external contributor, submitting small pull requests. - Reviewing and designing interfaces for es-toolkit provided valuable experience with JavaScript and API design. - Continued contributions eventually made her the project’s second-largest contributor and helped lead to her joining Toss Bank. - The project also demonstrated how an open-source initiative can connect contributors across companies and countries. ## Lowering the Migration Barrier with `es-toolkit/compat` - Adoption was initially slow because applications often imported many lodash functions throughout their codebases. - Replacing every import manually would make migration expensive and risky. - es-toolkit’s standard implementations also differed from lodash in some edge cases. - `es-toolkit/compat` was introduced as a drop-in replacement: - It preserves lodash-compatible interfaces and behavior as much as possible. - It modernizes the internal implementations. - Projects can gain performance and bundle-size benefits with minimal code changes. - This helped major projects such as Storybook, Mermaid, Yarn Berry, and Recharts adopt es-toolkit. ## Future Direction - es-toolkit plans to help more JavaScript libraries reduce their bundle sizes and improve efficiency. - It aims to add modern utilities, including: - `filter`-style functions for `Map` and `Set`. - Promise-based helpers such as `delay`. - Server-oriented utilities for Node.js, Deno, and Bun. - New functions such as `exec` are intended to provide essential functionality with smaller implementations than competing libraries. - The project plans to maintain its core principle: optimize for more than 80% of common use cases while remaining small, fast, and high quality. es-toolkit’s success shows that a focused, modern implementation can replace widely used legacy utilities when it combines measurable technical benefits with strong migration support and active community participation.

Read original(opens in new tab)
toss3 min readCurated summary

Why Does Our Team’s Documentation Fail? (1)

Documentation often fails not because people lack motivation, but because it depends on individual initiative and lacks clear standards. Interviews with a commerce domain and a server chapter showed that teams struggle to know what to document, how much detail to include, and whether their knowledge is accurate. Both organizations found that consolidating scattered knowledge into a shared system is the essential first step. ## Documentation in Domains and Chapters - **Domains** bring together developers, product owners, and designers around a business area such as commerce or advertising. - Their documentation focuses on product-related knowledge, including policies, terminology, and specifications. - **Chapters** group people with the same profession, such as server or frontend engineers. - Their documentation focuses on shared technical knowledge, conventions, and tools. - Dongjin works on consolidating internal knowledge across commerce and advertising domains, while Hyebin develops the company-wide documentation system “Todoc” and runs a documentation guild in the server chapter. ## Different Starting Points - The commerce domain already had strong awareness of documentation needs. - Members specifically requested terminology guides, policy documentation, experiment records, and API references. - Although writing standards were not clearly defined, people understood which documents would help their daily work. - The server chapter was initially more hesitant. - Members had worked without documentation and had not experienced its benefits directly. - An AI chatbot gave poor answers because its source documents were incomplete or disorganized. - Improving the underlying documents gradually made the chatbot more useful, helping members recognize the value of shared knowledge. ## Interviews Revealed the Real Obstacles - Dongjin interviewed developers to identify knowledge gaps and determine what information should be recorded. - The interviews clarified the organization’s needs, even though solving those needs required additional work. - Hyebin initially reviewed onboarding documents very thoroughly and repeatedly reminded people to complete them. - Interviews showed that contributors generally appreciated external review because it improved document quality. - The main problem was not a lack of motivation, but uncertainty: - What knowledge should be included? - How much detail is appropriate? - Is the information accurate enough to share? - These findings shifted the focus from persuading people to write toward making documentation easier and safer to produce. ## Problems Caused by Missing Documentation - In a domain, scattered policies create collaboration bottlenecks. - A team modifying a feature may first have to search for the policy owned by another team. - Newcomers struggle to understand what they do not know, creating prolonged “unknown unknowns.” - In a technical chapter, engineers often need to reconstruct the history behind unusual code. - They search old chat threads, try multiple keywords, or contact the original author. - More time may be spent assessing context and risk than implementing the change itself. - Useful knowledge often remains private. - Engineers may assume everyone already knows it or worry that it is too trivial to share. - As a result, people repeatedly solve the same problems independently, reducing overall productivity. ## Why Documentation Does Not Continue - Documentation benefits the future, while current work usually feels more urgent. - It is often treated as secondary work that requires a deliberate decision to begin. - Authors may also feel responsible for maintaining documents indefinitely. - Without documentation embedded in normal workflows, every update depends on personal willpower. - AI tools can reduce the effort of drafting and maintaining documents, but unclear standards and fear of being wrong remain significant barriers. Both organizations reached the same starting point: gather scattered knowledge in one accessible place, then integrate writing, review, and updates into everyday work rather than relying on individual motivation.

Read original(opens in new tab)
netflix3 min readCurated summary

The Data Canary: How Netflix Validates Catalog Metadata

Netflix built an automated “data canary” system to validate catalog metadata changes with real production traffic. The system compares a new catalog version against a known-good baseline, detects customer-impacting regressions in under 10 minutes, and blocks corrupted data before it reaches most members. The effort treats data deployments with the same rigor traditionally applied to code deployments. ## Why Catalog Data Needs Canarying - Catalog metadata defines available titles, artwork, playback eligibility, and regional availability. - A previous incident corrupted a feed without any code or configuration change. - The resulting empty data for some titles prevented manifest generation and caused playback failures. - Existing code canaries detected nothing because the failure occurred in transformed data, not application code. - Validating individual upstream feeds was insufficient because corruption could emerge during final transformation. ## Challenges of Fast, Production-Level Validation - Data cycles occur frequently, leaving only one cycle to detect problems and block publication. - Traditional canary analysis requires 30–60 minutes to reach statistical confidence. - Shadow traffic could replay catalog requests but could not reproduce the full playback lifecycle across services. - Real production traffic was necessary to expose actual customer impact. - The system also needed to contain regressions so that validation itself did not create a large outage. ## The Data Canary Orchestrator - Netflix created a dedicated canary environment with: - An orchestrator instance coordinating validation. - A permanent baseline cluster serving the latest production catalog. - A canary cluster receiving the new catalog version. - Before testing, the orchestrator verifies that both clusters are healthy and version-synchronized. - It then triggers a chaos experiment that compares customer behavior across the two versions. - Results are returned to the transformer through a generic REST endpoint, allowing other data sources to adopt the pattern without transformer-specific changes. ## Extending the Chaos Platform - Experiment thresholds were customized to meet the 10-minute detection requirement. - Separate tests were run for major client types because they have different traffic patterns and dependencies. - Playback traffic was especially effective at revealing failures. - Sticky canaries used session affinity to keep each user on either the baseline or canary cluster, enabling a clean comparison. - Starts Per Second (SPS) became the primary metric because it measures successful playback attempts more directly than latency or catalog-service error rates. - Metrics are streamed in real time, and experiments abort immediately when a regression appears. - This prioritizes rapid protection over maximum statistical confidence, which is appropriate given the strong customer-impact signal. ## Production-Hardened Reliability - The orchestrator resumes polling experiments after restarts instead of abandoning active validation cycles. - Leader election prevents multiple orchestrator instances from triggering duplicate experiments during deployment. - Version tracking ensures baseline and canary clusters are aligned across tenants with different data-consumption schedules. ## Controlled Failure Injection - Netflix validated the validator by deliberately corrupting catalog data. - Tests included denylisting prominent titles and simulating realistic data-corruption scenarios. - These experiments demonstrated whether the canary could identify meaningful playback regressions before corrupted metadata was broadly released. Netflix’s approach shows that high-velocity data pipelines require deployment safeguards distinct from code canaries. Teams managing critical data should validate final transformed outputs with representative production traffic, use direct business-impact metrics, and automatically stop publication when regressions appear.

Read original(opens in new tab)
netflix3 min readCurated summary

Data Projects: Managing Data Assets at Netflix Scale

Data Projects address Netflix’s difficulty managing millions of data assets and tens of thousands of workloads as teams and employees change. They replace asset-level permissions and human-owned workload identities with project-level grants and durable, synthetic identities. This makes access easier to maintain, workflows more resilient, and newly created assets easier to organize automatically. ## The Limits of Asset-Level Permissions - Netflix historically managed access through individual ACLs on each table. - Organizational changes required updating hundreds or thousands of permissions manually. - This overwhelmed support teams and encouraged overly broad access, such as granting access to the entire company. - The model did not scale with frequent reorganizations, team changes, and ownership transfers. ## The Limits of Human-Owned Workloads - Scheduled jobs and asynchronous workloads traditionally ran under the identity of their author. - When that person changed roles or left Netflix, the workload’s permissions changed or disappeared. - Reassigning the job to another employee often introduced new permission gaps. - This created a recurring “permissions whack-a-mole” across tens of thousands of business-critical workflows. ## Data Projects as a Management Container - A Data Project groups related tables, workflows, secrets, and other assets under one logical umbrella. - Teams manage permissions for the project instead of maintaining ACLs across every individual asset. - Grants can be assigned to users, groups, applications, and CI jobs. - Roles such as Contributor and Viewer define read/write or read-only access at the project level. ## Durable Project Identities - Each project receives a Netflix application identity and, optionally, an AWS IAM role. - Scheduled workloads execute as the project rather than as an individual employee. - The IAM role supports AWS use cases such as Spark jobs on Amazon EMR. - Privileged project members can assume the project identity from laptops or notebooks for testing and troubleshooting. - This provides a development context that matches the identity used in production. ## Gravity and Automatic Asset Organization - Assets created by workloads running under a project identity are automatically added to that project. - For example, tables created by a Maestro workflow become project assets without extra configuration. - This “gravity” keeps related outputs organized and makes future access and discovery easier. - Newly created assets inherit the project’s access model rather than requiring separate permissions. ## Securing Maestro Workflows - Maestro runs ETL pipelines, data movement jobs, machine-learning training, and other batch workloads. - As a Trusted Workload Manager, Maestro can mint identity tokens for scheduled executions. - A single workflow may be checked against table ACLs, Netflix resource policies, and AWS IAM policies. - Using a durable project identity prevents failures caused by changes to the original author’s account. - Project-scoped secrets also remain available when ownership changes. Data Projects provide Netflix with a scalable foundation for access control, workload execution, and asset ownership. Moving management from individual assets and employees to durable, team-owned projects makes the platform more stable, auditable, and resilient to organizational change.

Read original(opens in new tab)
netflix3 min readCurated summary

Predicting Risk in Content Launches: How Data-Driven Insights can Transform Launch Planning

Netflix developed boosted-tree models to predict when in-progress productions will deliver Locked Cuts and final IMF media. The models address gaps and inaccuracies in manually maintained schedules, improving delivery-date accuracy and providing earlier warnings of risk. Backtesting shows that predictive dates reduce error and Accumulated Error Days (AED), a measure strongly associated with launch delays. ## Launch Preparation and Schedule Risk - After production, titles move through post-production and launch preparation. - Final IMF assets trigger work on: - Artwork and trailers - Subtitles - Maturity ratings - Quality control - Teams can begin earlier with a non-final Locked Cut, but later changes may require conformance work. - Waiting for the IMF risks compressing the launch timeline if delivery is late. ## Problems with Manual Schedules - Delivery estimates are manually supplied by content partners. - Schedules often contain missing dates and inaccurate estimates. - Dynamic production conditions—schedule changes, conflicts, and unforeseen obstacles—frequently cause delays. - Predictive modeling can fill missing ETAs and improve existing ones. ## Accumulated Error Days and Launch Misses - Accumulated Error Days (AED) measures the cumulative difference between estimated and actual delivery dates. - Titles with launch misses have significantly higher mean AED than titles without misses. - Inaccuracies close to delivery are more strongly associated with launch misses than errors accumulated over longer periods. - Improving schedule accuracy near launch is therefore especially valuable. ## Predicting Time to Delivery - Netflix uses boosted-tree regression models to predict the number of days until Locked Cut or IMF delivery. - Models use: - Production progress signals - Title metadata - Seasonal indicators - Daily snapshots of production data - Snapshot-based modeling keeps predictions current and supports changing features throughout all production phases. ## Evaluating Predictive Performance - Netflix compares predicted and scheduled dates using: - Mean and median absolute error - Mean and median bias - Error standard deviation - Rates of large errors beyond specified day thresholds - Predictive dates offer full coverage, unlike schedules that may lack estimates at some horizons. - Backtesting showed lower errors and fewer outliers for predicted IMF and Locked Cut dates. ## Earlier Accuracy Signals - Predictions can become reliable earlier than manual schedules. - Six months before Locked Cut delivery, predictions were more accurate than scheduled dates for 76% of titles. - Their 6.1-week mean absolute error matched the accuracy of scheduled dates only 11 weeks later. - Across six months before delivery, predicted dates reduced AED for most buying organizations and content types. ## Integrating Predictions into Existing Workflows - Because delivery dates already support stakeholder workflows, predictive estimates can be introduced without redesigning those processes. - The remaining challenge is deciding when to trust scheduled dates versus predictions. - Although predictions are generally more accurate, manual schedules can still outperform them in some situations, requiring a way to select the more reliable estimate. Netflix’s modeling approach turns production data into an ongoing risk signal rather than relying solely on static partner schedules. Using predictive dates alongside existing workflows can give teams earlier, more accurate information for launch planning and help reduce avoidable launch delays.

Read original(opens in new tab)
netflix3 min readCurated summary

The Evolution of Cassandra Data Movement at Netflix

Netflix replaced its monolithic Cassandra-to-Iceberg connector, Casspactor, with a layered data movement engine built around direct reads from Cassandra backups in Amazon S3. Casspactor handled about 1,200 jobs and 3 PB daily but suffered from fragile metadata dependencies, skewed-partition failures, excessive intermediate tables, and limited support for higher-level data models. The new architecture uses Spark DataFrames and reusable, data-model-aware connectors to improve reliability, scalability, and cost efficiency. ## Casspactor’s Role and Limitations - Casspactor moved Cassandra data into Apache Iceberg using SSTables and metadata stored in S3 backups. - It supported critical Netflix workloads, including Member, Billing, Recommendations, and Subscriptions. - Its metadata view depended on several independent systems, each with different failure modes and update schedules. - Metadata could become inconsistent with actual backups, causing stale or incorrect data to be processed. - Cassandra maintenance or node replacement could break an entire region’s movement jobs because all nodes had to snapshot at the same clock second. ## Constraints for Higher-Level Data Abstractions - Cassandra-backed abstractions such as Key Value and Time Series inherited Casspactor’s limitations. - Large or skewed partitions caused executor memory failures and out-of-memory crashes. - Casspactor had no awareness of application-level data models, forcing downstream connectors to reconstruct them through costly post-processing. - Multiple intermediate Iceberg and snapshot tables increased storage costs and operational complexity. - Its backup composition model prevented reliable time travel to earlier backups after topology or keyspace schema changes. - The monolithic connector could not serve as a reusable foundation for specialized connectors. ## Direct S3 Metadata as the Source of Truth - The new design reads backup metadata directly from the S3 storage layer. - This removes the chain of external metadata dependencies. - Backup existence and completeness are determined from the files that actually contain the data. - Direct backup access also enables restoration of historical backup states. ## A Layered Connector Architecture - The Cassandra Analytics Wrapper builds on open-source Cassandra Analytics and Netflix’s internal backup format. - It uses an S3 client to read Cassandra backup files and convert them into standard Spark DataFrames. - A Connector Factory, implemented through Java UDFs and transforms, lets each abstraction define its own optimized connector. - Key Value, Time Series, and other models can transform generic DataFrames according to their own semantics. - Improvements to the shared reading engine automatically benefit every connector. ## Performance and Operational Improvements - Mutation compaction and processing run at Spark executor level, allowing better handling of wide and highly skewed partitions. - Reduced data shuffling helps prevent memory failures on large datasets. - Direct DataFrame output eliminates costly intermediary Iceberg tables. - Automatic job sizing adjusts resource usage based on source-table characteristics, reducing manual tuning. - Fewer dependencies improve reliability and make the system easier to maintain. Netflix’s new engine provides a shared, backup-native foundation while keeping data-model-specific logic in separate connectors. This approach is better suited to expanding Cassandra abstractions and large-scale data movement than maintaining another monolithic connector.

Read original(opens in new tab)
netflix3 min readCurated summary

Thinking Fast & Slow for a Personalized Notification System

Netflix’s personalized notification system separates long-term messaging strategy from real-time content selection. A “slow” policy sets each member’s personalized weekly pacing plan, while a “fast” policy chooses the best message when an opportunity arises. This hierarchy addresses the limits of short-term optimization by balancing immediate engagement with fatigue, opt-outs, and long-term member experience. ## Limitations of the Previous System - The earlier system used a causal model to estimate the short-term incremental effect of sending a single notification. - It optimized immediate actions, but could not capture cumulative effects such as: - Notification fatigue - Declining responsiveness over time - Sustained viewing behavior - Gradual opt-out risk - Send frequency and message ranking were coupled: - A relevance threshold implicitly controlled overall send volume. - Changing the threshold affected both frequency and the quality or distribution of selected messages. - Frequency could not be explicitly personalized according to each member’s engagement patterns. ## The Hierarchical Slow-Fast Architecture - The **Slow policy** makes strategic decisions over a longer horizon, such as a week. - It selects a personalized “Pacing Plan Action” that defines intended push and email frequencies. - The action space contains roughly 100 combinations of cross-channel pacing strategies. - The **Fast policy** operates in real time, selecting the most relevant message within the limits established by the slow policy. ## Utility-Based Strategic Planning The Slow policy chooses the action that maximizes a personalized utility function: `U(member, action) = Σ wₖ · Rewardₖ(member, action) — Cost(action)` - Positive signals estimate whether a member will value and engage with notifications. - Negative signals estimate fatigue and the likelihood of opting out of a channel. - Explicit negative feedback is sparse, so predicted messaging costs alone are too small to prevent excessive sending. - Netflix adds a universal cost to every message, ensuring that the utility remains well-behaved and discourages “always send” strategies. - This cost is tuned through online experiments and offline evaluation. ## Pacing Messages Over Time - A basic pacing strategy converts the target frequency into a per-opportunity probability. - At each eligible opportunity, the system uses weighted randomization to decide whether to send. - This produces a naturally varied schedule while maintaining the desired expected frequency. - The architecture can also support structured patterns, including: - Day-of-week preferences - User-activity-based pacing - Bursts aligned with product launches ## Communication Between Policies - The Slow policy calculates a member’s plan and stores it in a low-latency feature store. - The Fast policy retrieves that plan whenever a notification opportunity occurs. - This asynchronous event-and-state design lets the planner focus on long-term member health while the executor focuses on immediate relevance. The main recommendation is to decouple notification frequency and pacing from message ranking. A hierarchical system can explicitly manage long-term communication strategy while preserving the responsiveness and personalization of real-time selection.

Read original(opens in new tab)
netflix4 min readCurated summary

A Human-Augmenting Agentic Workflow for Causal Inference

The post presents a human-augmenting agentic workflow for observational causal inference (OCI), designed to automate repetitive analysis while preserving expert oversight. It combines an actor agent that executes analyses with a critic agent that evaluates assumptions, diagnostics, and credibility. The authors argue that transparent artifacts and process audits are essential because observational analyses rarely have definitive ground truth. ## Why Causal Inference Requires Oversight - Data agents can quickly query data and run regressions, but may overlook confounding, selection bias, or differences between average users and specific subgroups. - OCI requires substantial domain judgment, particularly when estimating effects from observational data under an unconfoundedness assumption. - Automation is best used to reduce repetitive work—such as repeated balance checks, sensitivity analyses, and tracking iterations—so practitioners can focus on framing questions and scrutinizing assumptions. ## Target Trial Emulation and Design Diagnostics Netflix’s OCI toolkit frames each analysis around the ideal randomized controlled trial that would answer the question. - This “target trial” clarifies the treatment, outcome, population, timing, and assumptions required for a credible estimate. - The workflow evaluates: - **Covariate balance:** weighted standardized mean differences should generally be below 0.2. - **Overlap:** propensity scores should remain between 0.1 and 0.9. - **Placebo outcomes:** treatment should not appear to affect variables measured before treatment. - **Sensitivity to hidden confounding:** estimated effects should be assessed against hypothetical omitted variables. - These diagnostics help identify whether treated and untreated groups are sufficiently comparable. ## Human-Augmenting Agent Design The workflow uses three personas: - **Principal:** The human data scientist who defines the research question, context, threats to validity, tools, and data. - **Actor:** The software agent that turns the plan into an analysis specification, executes the analysis, runs diagnostics, and produces reproducible artifacts. - **Critic:** The software agent that reviews the plan and results, identifies omissions, assesses credibility, and recommends improvements. The actor and critic operate in an iterative loop. Actors must use only approved tools, create human- and machine-checkable outputs, and report how they address failed diagnostics. Critics check for missing confounders, inconsistencies between the plan and execution, differences between the estimated estimand and the ATE, and gaps relative to the ideal randomized trial. ## Transparent Evaluation Through Artifacts Because observational data generally lacks ground truth, evaluating an agent solely by comparing its answer to a known result is insufficient. - Agents produce plans, specifications, plots, reports, and executed notebooks. - Reports are version-controlled and notebooks are stored so principals can download and re-run them. - Human reviewers can inspect every analytical step rather than trusting only the final estimate. - The workflow also supports conventional evaluations using simulated datasets, while emphasizing process audits for real-world analyses. ## Empowering Practitioners The system provides a templated notebook built on Netflix’s vetted, non-agentic OCI toolkit. - The toolkit uses doubly robust learning for causal effect estimation. - Humans remain responsible for writing the initial analysis plan and reviewing the executed notebook and critic’s report. - The design is intended to extend beyond unconfoundedness-based OCI to methods with different assumptions, such as panel methods requiring parallel trends. ## Case Study: New Entertainment Types Netflix applies the workflow to questions about whether newer entertainment offerings affect member satisfaction and subscription retention. - The case study focuses on an entertainment category referred to as **Type X**. - The broader goal is to estimate effects that could inform business strategy and understanding of member behavior. - The workflow is positioned as a way to combine automated analysis with human judgment in this setting. The recommended approach is not to let an agent make an unaudited causal claim. Instead, practitioners should use agents to execute standardized analyses and diagnostics, then inspect reproducible artifacts and critically assess the assumptions behind the result.

Read original(opens in new tab)
github3 min readCurated summary

How we built an internal data analytics agent

Qubot is GitHub’s internal, Copilot-powered analytics agent, designed to make warehouse data accessible without requiring an analyst. Employees ask natural-language questions through Slack, VS Code, or the Copilot CLI, while Qubot uses curated context and selects between Kusto and Trino to produce answers. GitHub’s experience shows that structured context is central to improving both accuracy and response speed. ## The Problem Qubot Addresses - Product teams often struggle to identify the right data model, grain, filters, and query. - Limited analyst availability leaves many teams to investigate telemetry independently. - Qubot targets exploratory questions rather than replacing dashboards or formal reporting. - It enables employees to investigate unfamiliar datasets with minimal setup and maintenance. ## Multiple Ways to Ask Questions - **Slack:** Users ask questions in a shared channel, receive answers in threads, and collaborate on follow-up questions. - Each result is saved as a Markdown report in a pull request, allowing users to refine queries or reuse them in dashboards. - **VS Code and Copilot CLI:** Qubot is installed as a plugin and operates alongside other agents, skills, and tools. - Offering both zero-configuration and developer-focused interfaces increased adoption among different user groups. ## A Federated Context Layer Qubot’s context is tailored to GitHub’s warehouse layers: - **Bronze:** Product teams provide telemetry schemas and metadata for raw events. - **Silver:** Data teams maintain query examples, usage guidance, and required filters for conformed data. - **Gold:** Dataset owners contribute business rules and metric definitions. - ETL pipelines add derived metadata and other signals automatically. - Context is fetched at runtime through the GitHub MCP Server. A dedicated context agent standardizes contributions from different teams. It ingests Markdown documentation and repository references, then organizes and normalizes them into a structure that Qubot can use effectively. ## Evaluation Before Deployment Every change to Qubot’s instructions or context layer is tested through an offline evaluation framework. - Test cases contain prompts, expected answers, ground-truth SQL, domains, and difficulty levels. - Automated orchestration launches multiple parallel agent trials using `gh agent-task create`. - Results are saved as JSON and aggregated by completion rate, accuracy, and duration. - Teams compare configurations and detect regressions before releasing changes. ## Choosing Between Kusto and Trino Qubot connects to both query engines through MCP servers: - **Kusto** is used for fast exploration of recent event data. - **Trino** handles complex joins and deeper historical analysis. - Qubot defaults to Kusto and switches to Trino when the question requires more advanced or historical querying. - This hides query-engine selection from users. ## Adoption and Lessons Learned - Hundreds of GitHub employees have run thousands of queries through Qubot. - Routine questions in analytics support channels declined as teams gained more autonomy. - The agent helped employees who previously avoided the warehouse access data for decision-making. - GitHub found that well-structured, carefully maintained context improved accuracy and made Qubot approximately three times faster at finding the right answer. The main recommendation is to treat analytics context as a maintained engineering asset. A capable agent depends not only on model intelligence, but also on accurate metadata, documented business rules, evaluation-driven iteration, and interfaces that fit users’ existing workflows.

Read original(opens in new tab)