Techlist.io - Korean Tech Blog Curator

figma2 min readCurated summary

What’s new in Figma: November 2021 | Figma Blog

Figma’s November 2021 updates focused on helping distributed teams collaborate more efficiently and inclusively. The main improvements redesigned comments to make feedback easier to notice and manage, while audio captions made real-time discussions more accessible to deaf and hard-of-hearing users. Together, these features reduce friction when teams move from ideas to decisions and deliverables. ## Redesigned Comments for Faster Feedback - Comments in both Figma and FigJam are now more prominent and easier to spot. - Adding and responding to comments has been simplified. - The redesign helps teams: - Share feedback more naturally - Organize and manage discussions - Act on feedback without interrupting their design workflow - The goal is to keep collaboration “in the flow” as teams iterate across functions. ## Audio Captions for More Inclusive Collaboration - Figma had previously introduced audio calls and cursor chat, allowing teammates to communicate without leaving a shared file. - FigJam also supports collaborative interactions such as high-fives during brainstorming sessions. - Closed captioning was added in beta to the Figma desktop app. - During audio discussions, captions make it clearer: - Who is speaking - What each person is saying - This improves participation for deaf and hard-of-hearing users and helps everyone follow important feedback. Figma’s November updates reinforce a practical collaboration principle: feedback should be easy to give, easy to understand, and accessible to every participant. Teams using Figma and FigJam can take advantage of redesigned comments and captions to make shared design work faster and more inclusive.

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

Stay in the flow with redesigned comments | Figma Blog

Figma redesigned comments in Figma and FigJam to make feedback easier to discover, understand, and act on without interrupting design work. The updates encourage more collaborators to participate, promote shorter and more contextual feedback, and provide better tools for managing large volumes of comments. Overall, the redesign aims to keep teams in the flow while incorporating feedback. ## Inviting More Collaborators - The comment sidebar is now easier to find for viewers opening a file. - Comments are also more visible in prototype presentation mode. - These changes help unfamiliar collaborators discover where to leave and review feedback. - Figma hopes increased visibility will encourage more contextual input instead of feedback through separate tools—or no feedback at all. ## Encouraging Clearer Feedback - The comment composer was made smaller to encourage concise, easier-to-follow responses. - Reactions let users quickly express opinions, keep threads shorter, and lower the barrier to participation. - Collaborators can select an area of the canvas to leave broader feedback about multiple designs, groups of stickies, or a general concept. - Area-based comments preserve the context of feedback, whether it concerns a broad layout or a small design detail. ## Managing Feedback During Design Work - Comment pins are visible by default, making feedback harder to overlook. - Designers can keep comments open while editing the canvas, allowing them to reference feedback without leaving their workflow. - A simplified canvas view makes it easier to see where feedback is concentrated. - Comment pins display avatars and provide previews on hover. - Comments in the same area are grouped into clusters to reduce visual clutter. - Users can search comments by keyword or person and sort them by date. - Comments can be marked as “unread” as a reminder to return to them later. Figma’s redesigned comments make collaboration more accessible and structured, particularly during design critiques, sprints, and iterative review. The practical recommendation is to use concise, contextual comments and the new search, clustering, and unread features to keep feedback manageable.

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

Behind the build: a Q&A with developer Gavin McFarland | Figma Blog

Gavin McFarland, a freelance design consultant and developer, discusses building a FigJam table widget after first creating a popular Figma table plugin. The widget lets users manage tabular data without leaving FigJam, supporting columns, rows, data import, and sorting. His experimentation with the widget API evolved into broader questions about multiplayer collaboration, performance, and productivity. ## Gavin’s Path to Plugin Development - McFarland began by designing and building websites for friends and family. - As a freelance consultant focused on user-centered digital transformation, he regularly pushes himself to learn new tools. - After seeing someone ask for an easier way to create tables in Figma, he modified the Rectangle Creator example into his first plugin, **Table Creator**. - The plugin eventually gained tens of thousands of users. ## Building a Table Widget for FigJam - McFarland created a FigJam table widget for users who need to display and manage structured data during collaborative work. - The widget supports: - Adding rows and columns - Importing data - Sorting by columns - The goal is to keep users inside FigJam rather than requiring a separate tabular-data application. ## Learning the Widget API - He began with the FigJam notepad example and made incremental modifications to understand the API. - The project required learning JSX, which he had not previously used extensively. - After understanding the basics, he experimented with rendering rows, columns, and different visual designs. ## Collaboration and Multiplayer Challenges - What started as an API exercise became an exploration of how teams could work more effectively together. - McFarland considered: - How simultaneous editing should work when multiple people modify one table - How the interface could show that another collaborator is active - How to keep large datasets responsive during multiplayer interactions - These challenges appealed to him because they combine visual design with technical problem-solving. ## Finding Ideas Through the Community - McFarland looks for problems designers encounter in their everyday workflows. - He draws inspiration from the Friends of Figma Slack community and the broader developer community. - Conversations with other plugin creators help him exchange ideas and improve his own work. ## Focus on Practical Productivity - He hopes the widget helps people work more productively and collaborate more closely. - His broader motivation is creating tools that address real, everyday problems. - The article ends as he begins discussing another plugin, **Node Decoder**, so the remainder of that project description is not included.

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

From candidate interviews to developer crits: how Figma engineering uses FigJam to scale | Figma Blog

Figma Engineering uses FigJam as more than a brainstorming tool: it supports team culture, hiring, collaboration, and technical feedback in a rapidly growing, hybrid workplace. By moving activities such as stand-ups and architecture interviews onto a shared digital canvas, the team preserves the spontaneity of in-person collaboration while creating a persistent record of discussions and ideas. ## Supporting Remote Team Culture - Remote stand-ups had become transactional and often ran over time as the team grew. - Engineers now post updates asynchronously in FigJam during a timed, 10-minute session. - Team members can add stickies, photos, reactions, hearts, and comments, making it easier to share personal updates and connect informally. - The shared canvas also encourages playful traditions, such as “20-second animal,” where everyone draws a selected animal at the end of a meeting. ## Scaling Engineering Processes - Figma’s mobile team grew to more than 20 people, creating a need for processes that scale with the organization. - Engineers focus on helping new teammates learn the company’s infrastructure and technology stack. - FigJam provides a shared space for organizing information and maintaining collaboration as teams expand. ## Digital Whiteboarding for Candidate Interviews - Engineering interviews include architecture and system-design exercises designed to reveal how candidates think and collaborate. - When interviews moved online, Figma replaced physical whiteboards with FigJam. - Interviewers share a prompt, observe candidates as they develop a solution, and discuss the design together on the virtual canvas. - Candidates unfamiliar with FigJam receive a brief orientation, and open sessions allow them to participate without creating an account. - The process retains the collaborative nature of in-person whiteboarding while working within Figma’s hybrid model. Figma’s approach demonstrates how a shared, flexible canvas can support both serious technical work and informal team connection. For distributed engineering teams, combining asynchronous updates, collaborative whiteboarding, and lightweight social activities can help preserve culture while processes scale.

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

Behind the build: a Q&A with developer Tekeste Kidanu | Figma Blog

Tekeste Kidanu, known online as tk made it, builds Figma and FigJam plugins that address practical needs from the design community. His best-known project, SPELLL, provides grammar and spell checking inside design files, while his newer FigJam tools support note-taking, color customization, and voting. He credits community feedback, Figma’s approachable plugin API, and his interest in design for shaping his work. ## Background and Motivation - Tekeste is an introverted frontend developer who moved to the U.S. in 2016 to study computer science. - He became interested in improving his design skills, particularly in color theory and typography. - He contributes to the Figma Community by creating tools that help designers work more productively. ## SPELLL: Spell Checking for Figma and FigJam - SPELLL scans Figma and FigJam documents for spelling and grammar errors. - Users can correct mistakes directly, similar to using Grammarly. - The plugin aims to save designers time and prevent embarrassing typos during presentations. - Tekeste developed the idea after seeing requests on the Figma Forum, Designer News, Twitter, and other design communities. ## Learning the Figma Plugin API - Tekeste researched how the plugin should work before beginning development. - He taught himself the Figma plugin API through its documentation and questions in the Figma Plugins Slack workspace. - He was surprised by how easy it was to begin, finding that his existing JavaScript and web-development knowledge provided a strong foundation. ## Building for FigJam - When FigJam introduced plugin support, Tekeste began adapting his existing Figma tools. - The similar APIs and development processes for Figma and FigJam made migration straightforward. - His FigJam projects include: - **Notes**, a widget for storing detailed plain-text or Markdown notes without cluttering a board. - **Color Picker**, which adds custom-colored stickies and shapes. - **Voting**, which supports anonymous and non-anonymous voting sessions. ## Community-Driven Inspiration - Tekeste frequently finds ideas in feature requests and discussions on Twitter, the Figma Forum, and Friends of Figma Slack. - He notes that many requested features can be implemented through the plugin API before Figma adds them natively. - He hopes another developer will build a FigJam widget showing what music participants are listening to. ## Looking Ahead - Tekeste plans to improve his voting widget and make it the best possible tool for FigJam sessions. - He is excited about the public release of FigJam plugins and widgets and the creativity it may encourage. - He is also inspired by the growing popularity of playful, animated, and interactive interfaces, citing Apple Maps and the Honk app as examples. Figma’s open plugin and widget platform gives developers like Tekeste a practical way to turn community requests into useful design tools. His work demonstrates how existing web skills, combined with active listening to users, can produce focused improvements to collaborative workflows.

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

Behind the build: a Q&A with developer Tru Narla | Figma Blog

The post profiles Tru Narla, a software engineer and creator of FigJam’s Soundboard widget. Her project adds playful audio interactions to FigJam boards and demonstrates how accessible the widget platform can be for developers. Despite API limitations, documentation, experimentation, community support, and livestreaming helped her turn a side-project idea into a published product. ## Soundboard for FigJam - Soundboard lets users add fun sounds to FigJam boards. - Tru initially wanted to support user-recorded audio and preset sounds, but widget limitations prevented audio recording. - The idea came from wanting to create an interactive experience focused specifically on sound. ## Building the Widget - Tru began by reading the documentation and studying demo projects. - Much of the development involved trial and error and reducing the project’s scope to fit the available APIs. - A private Slack community for widget developers helped her share code, troubleshoot bugs, and stay motivated. - She found widget development easier and more enjoyable than expected. ## Inspiration and Motivation - Tru draws ideas from Twitter and everyday experiences. - She records potential project ideas and prefers building tools she would personally use. - Publishing a finished project was a major motivation after repeatedly starting—but not completing—side projects. - Streaming the development process on Twitch provided additional accountability and encouragement. ## Future Projects and Platform Potential - Her next project is an interactive piano with clickable keys and keyboard shortcuts mapped to different notes. - She is also considering multiplayer games, though they require more planning and development time. - Tru is excited by FigJam’s growing ecosystem of plugins and widgets and the possibilities still open to developers. - She particularly likes the new code embed feature and imagines using it for tutorials, system design, and code explanations. - She would also like to see running code displayed in a sandbox within FigJam. Tru’s experience suggests that developers can begin with a small, playful idea, use the available documentation and community resources, and gradually expand their ambitions as the FigJam platform evolves.

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

What’s new in Figma: October 2021 | Figma Blog

Figma’s October 2021 updates focus on making collaboration more flexible, prototyping faster, and design work easier to scale. FigJam gained widgets, plugins, templates, code blocks, advanced shapes, and open sessions, while Figma introduced interactive components and several workflow improvements. Together, these features aim to balance structured teamwork with experimentation and spontaneous collaboration. ## Work Better Together in FigJam - **Widgets** can be added directly to FigJam files to support activities such as: - Taking team selfies with Photo Booth - Checking team sentiment with Alignment Scale - Mapping organizational structures with Org Chart - **Plugins** help users develop and synthesize ideas more efficiently: - Tour Guide turns jam boards into slideshow presentations. - Color Picker expands color options for stickies and shapes. - Unsplash provides access to image libraries. - The FigJam toolbar now provides access to: - Plugins and widgets - Templates for brainstorming, workshops, research, and other activities - Code blocks and new shapes for technical collaboration - **Open sessions** allow visitors to join FigJam files without creating an account. ## Bring Designs to Life with Interactive Components - **Interactive components** create reusable interactive elements, reducing the amount of manual prototyping required. - Designers can experiment and iterate more quickly while collaborating with their teams. - Interactions inherited from main components are hidden on instances, making complex prototypes easier to understand and edit. - Additional prototyping improvements include: - `Shift + E` to switch between Design and Prototype tabs - Canvas visibility for interactions, allowing everyone to inspect and explore them - An option to disable keyboard navigation in prototype viewers for more realistic user testing - Copying and pasting prototype interactions to reduce repetitive work ## Explore and Design at Scale - Figma emphasizes supporting design systems while still leaving room for experimentation and new ideas. - The update introduces **branching**, presented as a way to help teams manage and explore design-system work at scale.

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

Interactive components: Less wiring, more inspiring | Figma | Figma Blog

Figma’s October 2021 update introduces interactive components as a way to bring reusable interactions and animations directly into the design workflow. By reducing manual prototype wiring and the number of required frames, the feature helps teams create, iterate on, and share more realistic prototypes. Additional improvements make switching between design and prototyping, managing complex canvases, and reusing interactions faster. ## Interactive Components - Interactive components let designers define interactions and animations between variants in a component set. - Component instances become immediately interactive in prototyping mode. - A single frame can replace many frames for states such as: - Multiple selected checkboxes - Open accordion menus - Button hover states - Teams reported prototype frame reductions of up to 10 times. - Designers can edit component states beside where the component is used and duplicate versions to explore alternatives. - Interactive components can be distributed through shared libraries, allowing teams to reuse preconfigured interactions with one click. - Figma improved performance, load times, stability, observation mode, and auto layout support after the beta period. ## Faster Prototyping Workflows - The shortcut **Shift + E** toggles between the Design and Prototype tabs without losing context. - Interactions inherited by instances from main components are hidden on the canvas, reducing visual clutter from numerous blue prototype arrows, or “noodles.” - Prototype interactions can be copied and pasted into frames, reducing repetitive setup work. ## Broader Impact on Design Teams - Interactive components narrow the gap between visual design and interactive behavior. - Reusable interactions help designers focus on user flows instead of manually wiring repeated states. - Shared libraries make it easier for less experienced Figma users to build functional prototypes. - The feature also supports more experimental prototypes, including animated objects, music notation, and interactive games or toys. Figma’s recommendation is to use interactive components and its playground file to make prototyping a more integrated, reusable, and iterative part of the design process.

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

​​Open sessions: jam with anyone, anywhere | Figma Blog

FigJam’s Open sessions let people join collaborative files without creating Figma accounts, removing friction for workshops, interviews, and meetings. Hosts retain control over access: sessions close after 24 hours by default, visitors are removed afterward, and hosts can end or restart sessions at any time. The feature is designed primarily for one-off collaborations with internal or external participants. ## Removing Barriers to Participation - Account creation can delay workshops, interviews, and other collaborative activities. - Open sessions allow occasional participants—including clients, candidates, research users, and cross-functional colleagues—to join immediately. - Participants can contribute without setup or an existing Figma account. ## How Open Sessions Work - Hosts choose when and how to open a FigJam file. - Visitors are removed automatically when the session ends. - Each session expires after 24 hours by default. - Hosts can close a session early or start another session for the same file. ## Common Use Cases - **Workshops:** Invite clients or research participants to collaborate directly in FigJam. - **Interviews:** Share a file with candidates in advance so they can present their work; technical interviews can use the CoderPad widget. - **Cross-functional meetings:** Include stakeholders in planning meetings, retrospectives, brainstorming sessions, and feedback discussions. - **One-off jams:** The feature is intended for both large-group events and one-on-one sessions. ## Availability - Open sessions were available across all plans while FigJam was in beta. - Beginning February 1, 2022, the feature became available on FigJam Professional and Organization plans. Open sessions are best suited to temporary collaboration where ease of access matters more than requiring every participant to maintain an account.

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

Introducing new FigJam prices and a more open platform | Figma Blog

FigJam is expanding from a beta whiteboard into a more accessible, customizable collaboration platform. Figma announced free and paid pricing, lower-friction participation through Open sessions, and a broader ecosystem of widgets, plugins, embeds, templates, shapes, and code blocks. The goal is to help entire organizations use FigJam for meetings, workshops, visual thinking, and everyday productivity. ## More accessible pricing and participation - Starting February 1, 2022, FigJam’s Starter plan will remain free. - The free plan includes: - Unlimited personal whiteboards - Three shared whiteboards - Unlimited collaborators - Paid plans provide unlimited shared whiteboards: - FigJam Professional: $3 per editor per month - FigJam Organization: $5 per editor per month - **Open sessions** let anyone join a FigJam session for 24 hours without logging in, making one-off workshops and planning meetings easier to host. ## Widgets for collaboration and meetings Widgets allow teams to customize FigJam and support social, facilitation, and productivity workflows. - **Team connection:** Donut offers water-cooler prompts and drawing games; other widgets include Rock Paper Scissors and Connect Four. - **Meeting facilitation:** - Simple Vote collects feedback after brainstorming. - Alignment Scale checks whether participants agree. - **Productivity support:** - Table imports Google Sheets data into FigJam. - Stark for FigJam provides accessibility checklists and guidance. - Org Chart helps map departments and plan headcount. - Figma planned to expand widgets with kanban boards, timelines, inline text editing, and improved media embedding. ## Plugins for faster creation - Plugins focus on helping users express and create ideas more quickly, while widgets emphasize collaborative interaction. - More than 40 plugins were already available. - Vimeo was developing a Vimeo Record plugin for recording screen captures and voice-over explanations directly in a FigJam file. - Other examples include: - Tour Guide for animated presentations - Create Sticky from Text for converting text into sticky notes - Stamp Counter for quickly counting votes ## A broader, community-built platform - Figma opened FigJam’s widgets and plugins platform to developers after an initial community beta. - The company positioned this open ecosystem as a way to let users shape how FigJam works for different teams and use cases. - Additional platform improvements announced included embedded content such as videos and documents, new shapes and code blocks, and templates accessible from the FigJam toolbar. FigJam’s strategy is to combine broad access with extensibility: keep basic collaboration free, remove barriers for guests, and let teams adapt the workspace through community-built tools.

Read original(opens in new tab)
datadogOriginal article

Our journey taking Kubernetes state metrics to the next level | Datadog (opens in new tab)

Datadog’s container observability team significantly improved the performance of kube-state-metrics (KSM) by contributing core architectural enhancements to the upstream open-source project. Faced with scalability bottlenecks where metrics collection for large clusters took tens of seconds and generated massive data payloads, they revamped the underlying library to achieve a 15x improvement in processing duration. These contributions allowed for high-granularity monitoring at scale, ensuring that the Datadog Agent can efficiently handle millions of metrics across thousands of Kubernetes nodes. ### Challenges with KSM Scalability * KSM uses the informer pattern to expose cluster-level metadata via the Openmetrics format, but the volume of data grows exponentially with cluster size. * In high-scale environments, a single node generates approximately nine metrics, while a single pod can generate up to 40 metrics. * In clusters with thousands of nodes and tens of thousands of pods, the `/metrics` endpoint produced payloads weighing tens of megabytes. * The time required to crawl these metrics often exceeded 15 seconds, forcing administrators to reduce check frequency and sacrifice real-time data granularity. ### Limitations of Legacy Implementations * KSM v1 relied on a monolithic loop that instantiated a Builder to track resources via stores, but it lacked efficient hooks for metric generation. * The original Python-based Datadog Agent check struggled with the "data dump" approach of KSM, where all metrics were processed at once during query time. * To manage the load, Datadog was forced to split KSM into multiple deployments based on resource types (e.g., separate deployments for pods, nodes, and secondary resources like services or deployments). * This fragmentation made the infrastructure more complex to manage and did not solve the fundamental issue of inefficient metric serialization. ### Architectural Improvements in KSM v2.0 * Datadog collaborated with the upstream community during the development of KSM v2.0 to introduce a more extensible design. * The team focused on improving the Builder and metric generation hooks to prevent the system from dumping the entire dataset at query time. * By moving away from the restrictive v1 library structure, they enabled more efficient reconciliation of metric names and metadata joins. * The resulting 15x performance gain allows the Datadog Agent to reconcile labels and tags—such as joining deployment labels to specific metrics—without the significant latency overhead previously experienced. Contributing back to the open-source community proved more effective than maintaining internal forks for scaling Kubernetes infrastructure. Organizations running high-density clusters should prioritize upgrading to KSM v2.0 and optimizing their agent configurations to leverage these architectural improvements for better observability performance.

datadog3 min readCurated summary

Our journey taking Kubernetes state metrics to the next level

Datadog contributed major scalability improvements to kube-state-metrics (KSM), after discovering that its metric collection process struggled with very large Kubernetes clusters. Millions of metrics could require tens of megabytes and tens of seconds to process every 15 seconds, forcing Datadog to reduce collection frequency. Their redesign improved collection duration by 15x and enabled more granular monitoring at scale. ## Datadog’s Kubernetes Observability Role - The Datadog Containers team monitors Kubernetes infrastructure and ensures reliable collection of: - Logs - Traces - Custom metrics - Profiles - Security signals - KSM is central to Datadog products such as Kubernetes metrics integration and Orchestrator Explorer. ## How Kubernetes State Metrics Works - KSM uses Kubernetes informers to watch objects registered with the API server. - Enabled collectors monitor resources such as pods, nodes, deployments, and services. - It generates lifecycle and metadata metrics in text-based OpenMetrics format. - Users can restrict monitored resources through the `resources` flag. - The Datadog Agent’s KSM check: - Runs every 15 seconds. - Discovers KSM containers. - Crawls their `/metrics` endpoint. - Reconciles metric metadata and applies configured label joins. - Label joins allow metadata from one metric, such as a deployment label, to become a tag on other metrics for the same object. ## Scaling Challenges - Datadog found that KSM needed to be split across multiple deployments beyond a few hundred nodes and thousands of pods. - Their deployments divided collectors by resource type: - Pods - Nodes - Services, deployments, jobs, persistent volumes, and other resources - Metric volume varied substantially: - Endpoints, jobs, and deployments produced roughly five metrics per object. - Nodes produced around nine metrics each. - Pods produced around 40 metrics each. - Large clusters with thousands of nodes and tens of thousands of pods could generate millions of metrics per scrape. - Crawling the metrics endpoint could take tens of seconds and transfer tens of megabytes. - Datadog had to reduce check frequency, sacrificing metric granularity and user experience. ## KSM’s Original Architecture - KSM v1 relied on a central loop that created a Builder and managed resource stores. - Each store used informers to track a particular Kubernetes resource. - For example, an HPA store maintained the list-and-watch logic for HorizontalPodAutoscalers. - The Builder generated metrics from the tracked resources. - Datadog identified two limitations: - Too much data was emitted and processed at query time. - The Builder did not provide a suitable extension point for custom metric-generation logic. ## Contributing the Redesign Upstream - As the KSM community prepared version 2.0 in early 2020, Datadog saw an opportunity to address its scalability and extensibility problems in the upstream project. - Rather than maintaining a private solution, the team contributed its findings and improvements to the open-source community. - The resulting work reportedly reduced metric collection duration by 15x, making high-scale, more frequent collection practical. Datadog’s experience shows that upstream open-source collaboration can solve internal infrastructure bottlenecks while improving the project for the broader Kubernetes community.

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

LiveGraph: real-time data fetching at Figma | Figma Blog

LiveGraph is Figma’s in-house real-time data-fetching layer built on PostgreSQL. It lets frontend developers declare live data views with GraphQL-like queries, while LiveGraph reads PostgreSQL’s replication stream to deliver updates within milliseconds. Figma built it to replace fragile, manually maintained client events and to support real-time subscriptions at large scale without relying on polling or a new database technology. ## Problems with Figma’s Earlier Real-Time Architecture - React clients initially loaded large data sets through Ruby HTTP endpoints and stored them in Redux. - Backend code manually emitted events whenever database records changed. - Frontends subscribed over WebSockets and applied those events to client state. - As data volumes grew, Figma split requests into incremental loads, making data ownership and availability harder to reason about. - Complex changes—such as permission updates affecting many resources—were difficult to represent with individual events. - Events could arrive out of order or fail to correspond reliably with database writes, causing client state to diverge from server state. ## Why Figma Chose Live Queries - Figma wanted developers to define data subscriptions declaratively rather than manually coordinate fetches and update events. - GraphQL provided a natural interface for describing the relevant portion of the object graph. - LiveGraph uses “live queries,” which keep query results synchronized, rather than GraphQL subscriptions in the narrower sense of consuming event streams. - The system is a query and data-fetching layer over existing PostgreSQL infrastructure, not a replacement persistence layer. ## In-House System Versus Existing Tools - Figma’s multiplayer service handles collaborative writes and conflict resolution within individual files, whereas LiveGraph focuses on reading application data. - Systems such as Hasura, Prisma, and PostGraphile offered GraphQL subscription features but were not designed primarily for Figma’s scale of concurrent live subscriptions. - Polling was rejected because it increases database load and requires developers to choose polling intervals for each query. - Figma’s collaborative product made real-time data central enough to justify building and operating a specialized internal system. - The company did not claim LiveGraph was universally superior; its value came from matching Figma’s specific scale and requirements. ## Replication-Stream-Based Updates - LiveGraph executes queries directly against PostgreSQL. - It tails the database replication log to detect changes instead of repeatedly polling tables. - Reading the replication stream enables update latency measured in milliseconds. - Because the system must process the complete volume of database changes, its architecture needs to distribute updates across machines and database shards. - This approach separates the complexity of detecting database changes from product code, allowing frontend engineers to work with declarative JSON data views. ## Frontend API - Product developers send GraphQL-like queries and receive results as JSON trees. - A schema defines server-side entities and relationships, while views expose queryable subsets of that graph. - The frontend can therefore request the data it needs and rely on LiveGraph to keep the result synchronized as the underlying PostgreSQL data changes. LiveGraph’s central recommendation is architectural: derive live client views from the database’s authoritative change stream rather than maintaining a parallel network of hand-written events. For organizations with similar scale and real-time requirements, this can improve consistency and simplify product development, though Figma’s in-house approach was justified by its unusually collaborative workload.

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

How (and why) we built branching | Figma Blog

Figma built branching to preserve the benefits of real-time collaboration without letting unfinished or experimental work disrupt approved designs. Branches provide isolated spaces for exploration while keeping the main file a reliable source of truth. The design prioritizes simplicity, familiar multiplayer behavior, and protection against data loss. ## The Need for Branching at Scale - Figma’s real-time multiplayer model usually helps teams work in one shared file. - As organizations grow, however, design workflows become harder to manage: - Unapproved changes can reach production code. - Work may be overwritten. - Teams may struggle to distinguish work in progress from approved designs. - Branches let designers experiment, iterate, contribute to libraries, or preview work without changing the main file. - Changes can be incorporated into the main file only after review and approval. ## Balancing Freedom and Structure - Growing design teams increasingly requested stronger version-control workflows. - Traditional branching comes from software development, where files and changes are stored locally. - Figma had to adapt the concept for cloud-based files, asking: - Whether people should continue editing the main file simultaneously. - How collaboration should work within branches. - How to introduce version control without overwhelming designers with complexity. ## Designing Around Figma’s Multiplayer Model - Figma chose a purpose-built approach rather than copying existing development tools. - Simplicity and consistency became core principles: - The main file remains multiplayer. - A branch behaves like a regular Figma file. - Existing editor and viewer permissions continue to apply. - The system emphasizes data safety so users’ changes remain protected. - Figma intentionally limited complexity, including preventing branches from being created from other branches. ## The Complexity of Merging - Merging involved more than simply resolving conflicting edits. - Figma also had to handle operational problems such as: - The file changing while someone reviews a merge. - A user losing their connection midway through the process. - These cases required safeguards to ensure merges remain understandable, recoverable, and safe. Branching is therefore presented as a structured layer on top of Figma’s collaborative model: teams can explore freely in branches while maintaining a dependable, approved main file.

Read original(opens in new tab)
datadogOriginal article

How we optimized our Akka application using Datadog’s Continuous Profiler | Datadog (opens in new tab)

Datadog engineers discovered a significant 20–30% CPU overhead in their Akka-based Java applications caused by inefficient thread management within the `ForkJoinPool`. Through continuous profiling, the team found that irregular task flows were forcing the runtime to waste cycles constantly parking and unparking threads. By migrating bursty actors to a dispatcher with a more stable workload, they achieved a major performance gain, illustrating how high-level framework abstractions can mask low-level resource bottlenecks. ### Identifying the Performance Bottleneck * While running A/B tests on a new log-parsing algorithm, the team noticed that expected CPU reductions did not materialize; in some cases, performance actually degraded. * Flame graphs revealed that the application was spending a disproportionate amount of CPU time inside the `ForkJoinPool.scan()` and `Unsafe.park()` methods. * A summary table of CPU usage by thread showed that the "work" pool was only using 1% of the CPU, while the default Akka dispatcher was the primary consumer of resources. * The investigation narrowed the cause down to the `LatencyReportActor`, which handled latency metrics for log events. ### Analyzing the Root Cause of Thread Fluctuations * The `ForkJoinPool` manages worker threads dynamically, calling `Unsafe.park()` to suspend idle threads and `Unsafe.unpark()` to resume them when tasks increase. * The `LatencyReportActor` exhibited an irregular task flow, processing several hundred events in milliseconds and then remaining idle until the next second. * Because the default dispatcher was configured to use a thread pool equal to the number of processor cores (32), the system was waking up 32 threads every second for a tiny burst of work. * This constant cycle of waking and suspending threads created massive CPU overhead through expensive native calls to the operating system's thread scheduler. ### Implementing a Configuration-Based Fix * The solution involved moving the `LatencyReportActor` from the default Akka dispatcher to the main "work" dispatcher. * Because the "work" dispatcher already maintained a consistent flow of log processing tasks, the threads remained active and did not trigger the frequent park/unpark logic. * A single-line configuration change was used to route the actor to the stable dispatcher. * Following the change, the default dispatcher’s thread pool shrank from 32 to 2 threads, and overall service CPU usage dropped by an average of 30%. To maintain optimal performance in applications using `ForkJoinPool` or Akka, developers should monitor the `ForkJoinPool.scan()` method; if it accounts for more than 10–15% of CPU usage, the thread pool is likely unstable. Recommendations for remediation include limiting the number of actor instances, capping the maximum threads in a pool, and utilizing task queues to buffer short spikes. The ultimate goal is to ensure a stable count of active threads and avoid the performance tax of frequent thread state transitions.