figma·Jan 25, 2026·2 min readCurated summary

Think Outside of the Box—with Claude and FigJam | Figma Blog

Figma and Anthropic have integrated FigJam with Claude so teams can turn AI conversations into editable diagrams. Users can generate flows, timelines, architecture diagrams, and other visual artifacts from prompts, PDFs, images, screenshots, documentation, or code. The integration is intended to make AI-assisted thinking more collaborative by moving ideas from a private chat into a shared workspace where teams can refine and act on them. ## Turning Conversations into Diagrams - Claude can create editable FigJam diagrams directly from written prompts and uploaded materials. - Product teams can generate user flows from PRDs to identify friction, edge cases, and missing steps. - Visualizing ideas reduces copy-pasting and context switching while making abstract concepts easier to discuss. - Teammates can comment, react, and build on the generated diagrams in FigJam’s shared canvas. ## Supporting Product Planning - Product managers can use Claude and FigJam to create initial project plans and Gantt charts. - Generated timelines can map milestones, dependencies, and sequencing. - Early visual drafts help teams spot planning problems, unblock work, and align more quickly. ## Helping Engineers Explain Complex Systems - Claude can generate diagrams from technical documentation or uploaded code files. - Diagrams can represent: - System architecture - Services and APIs - Databases and dependencies - Request and response flows - Sequence and state transitions - These diagrams provide shared context for front-end and back-end teams and help reduce implementation risk. - Claude can compare system patterns and suggest suitable visualization styles. ## FigJam as a Collaborative Workflow - Ideas generated in Claude can move into the broader Figma ecosystem: - Refined in Figma Design - Shared through Figma Slides - Translated into code - Figma is also improving FigJam with more advanced shape collections and connector types. - Anthropic has released a UI kit for designing Claude MCP apps in Figma. - The workflow connects brainstorming, planning, refinement, and execution in one process. ## AI as an Ongoing Collaborator - Multi-turn conversations let teams iteratively develop user journeys, prioritization strategies, and implementation plans. - Claude can propose alternative solutions and recommend chart formats such as decision trees, Gantt charts, sequence diagrams, and state diagrams. - FigJam diagrams become shared, evolving artifacts rather than one-off AI outputs. - Figma presents this integration as a step toward making complex systems easier for teams to understand and improve together. Teams can access the feature through the Figma Connector in Claude’s browser or desktop apps, with support listed for Claude Opus 4.5 and Sonnet 4.5.

Read original(opens in new tab)

System ArchitectureAIFigjamClaude+3

toss·Dec 10, 2025Original article

Legacy Settlement Modernization: From the (opens in new tab)

Toss Payments recently overhauled its 20-year-old legacy settlement system to overcome deep-seated technical debt and prepare for massive transaction growth. By shifting from monolithic SQL queries and aggregated data to a granular, object-oriented architecture, the team significantly improved system maintainability, traceability, and batch processing performance. The transition focused on breaking down complex dependencies and ensuring that every transaction is verifiable and reproducible. ### Replacing Monolithic SQL with Object-Oriented Logic * The legacy system relied on a "giant common query" filled with nested `DECODE`, `CASE WHEN`, and complex joins, making it nearly impossible to identify the impact of small changes. * The team applied a "Divide and Conquer" strategy, splitting the massive query into distinct domains and refined sub-functions. * Business logic was moved from the database layer into Kotlin-based objects (e.g., `SettlementFeeCalculator`), making business rules explicit and easier to test. * This modular approach allowed for "Incremental Migration," where specific features (like exchange rate conversions) could be upgraded to the new system independently. ### Improving Traceability through Granular Data Modeling * The old system stored data in an aggregated state (Sum), which prevented developers from tracing errors back to specific transactions or reusing data for different reporting needs. * The new architecture manages data at the minimum transaction unit (1:1), ensuring that every settlement result corresponds to a specific transaction. * "Setting Snapshots" were introduced to store the exact contract conditions (fee rates, VAT status) at the time of calculation, allowing the system to reconstruct the context of past settlements. * A state-based processing model was implemented to enable selective retries for failed transactions, significantly reducing recovery time compared to the previous "all-or-nothing" transaction approach. ### Optimizing High-Resolution Data and Query Performance * Managing data at the transaction level led to an explosion in data volume, necessitating specialized database strategies. * The team implemented date-based Range Partitioning and composite indexing on settlement dates to maintain high query speeds despite the increased scale. * To balance write performance and read needs, they created "Query-specific tables" that offload the processing burden from the main batch system. * Complex administrative queries were delegated to a separate high-performance data serving platform, maintaining a clean separation between core settlement logic and flexible data analysis. ### Resolving Batch Performance and I/O Bottlenecks * The legacy batch system struggled with long processing times that scaled poorly with transaction growth due to heavy I/O and single-threaded processing. * I/O was minimized by caching merchant contract information in memory at the start of a batch step, eliminating millions of redundant database lookups. * The team optimized the `ItemProcessor` in Spring Batch by implementing bulk lookups (using a Wrapper structure) to handle multiple records at once rather than querying the database for every individual item. This modernization demonstrates that scaling a financial system requires moving beyond "convenient" aggregations toward a granular, state-driven architecture. By decoupling business logic from the database and prioritizing data traceability, Toss Payments has built a foundation capable of handling the next generation of transaction volumes.

System ArchitectureDatabase DesignKotlinRefactoring+3

datadog·Aug 12, 2025·3 min readCurated summary

Scaling down to speed up: How we improved efficiency of live process metrics by 100x

Datadog redesigned its real-time Processes and Containers pipeline to avoid collecting high-frequency metrics that users never see. By limiting 2-second collection to hosts actively viewed and using standard 10-second data for sorting, the company reduced real-time traffic by over 100x, cut infrastructure costs by 98%, and lowered Agent resource usage. The approach also improved scalability without sacrificing the live investigation experience. ## Original Real-Time Collection Model - Datadog Agents normally collect process and container metrics every 10 seconds. - When a user opened a live Processes or Containers view, all hosts in that tenant switched to 2-second collection. - This supported near-real-time monitoring similar to `htop`, but across distributed infrastructure. - As tenants grew, the pipeline had to process millions of processes per second, even though users typically viewed only around 50 processes or containers. - Live sorting required keeping all tenant data in memory on a single server, limiting horizontal scaling and forcing vertical scaling. ## Refocusing on User-Visible Data - Most collected metrics were never displayed to users. - Datadog determined that real-time collection only needed to be enabled for hosts running the processes or containers currently in view—up to roughly 50 hosts per user. - Internal telemetry suggested this could reduce traffic by more than 100x. - This required tracking active host subscriptions and updating them as users navigated the product. - Because sorting occurred every 10 seconds, it did not need 2-second data. Datadog switched live views to use the existing 10-second metrics, aligning live and historical sorting logic. ## Host Subscription Filtering - A proof of concept added host subscriptions to the live data servers. - Servers filtered Kafka payloads and discarded data for hosts without active subscriptions. - This immediately reduced: - Memory usage by 85% - CPU usage by 33% - The improvement came from storing fewer live metrics and processing fewer incoming payloads. - The prototype confirmed that filtering preserved product behavior while simplifying sorting. ## Moving Filtering Earlier in the Pipeline - Late filtering improved live data servers but still left unnecessary work for the rest of the system and customer-side Datadog Agents. - Datadog therefore planned to propagate subscription state to the intake service. - Live data servers publish users’ active host sets over Kafka once per second. - The intake service consumes this information and decides which hosts should activate 2-second process and container metric collection. - This allows real-time collection to be restricted to hosts users are actively investigating while maintaining responsive live views. Datadog’s redesign demonstrates that real-time systems scale more effectively when they prioritize data users can actually see. Filtering at intake, limiting high-frequency collection to subscribed hosts, and reusing standard-resolution data for sorting provide a simpler and more economical architecture without eliminating live functionality.

Read original(opens in new tab)

System ArchitectureDatabase DesignDatadogApache Kafka+4