woowahan·Dec 26, 2025Original article

For a Seamless User Experience (opens in new tab)

To provide a seamless user experience, Baedal Minjok (Baemin) successfully integrated KakaoTalk brand vouchers directly into its ordering system, overcoming significant technical and organizational barriers between platforms. This project was driven by a mission to resolve long-standing customer friction and strategically capture external purchase demand within the Baemin ecosystem. By bridging the gap between Kakao’s gifting infrastructure and Baemin’s delivery network, the team successfully transformed a fragmented journey into a unified, user-centric service. ### Bridging User Friction and Business Growth - Addressed persistent Voice of Customer (VOC) complaints from users who found it inconvenient to use KakaoTalk vouchers through separate brand apps or physical store visits. - Aimed to capture untapped external traffic and convert it into active order volume within the Baemin platform, enhancing customer retention and "lock-in" effects. - Defined the project’s core essence as "connection," which served as a North Star for decision-making when technical constraints or business interests conflicted. ### Navigating Multi-Party Stakeholder Complexity - Coordinated a massive ecosystem involving Kakao (the platform), F&B brands, third-party voucher issuers, and internal Baemin backend teams. - Managed conflicting KPIs across organizations, balancing Kakao’s requirement for platform stability with voucher issuers' needs for settlement clarity. - Employed "context-aware communication" to bridge terminology gaps, such as reconciling Baemin’s "register and use" logic with the voucher companies' "inquiry and approval" workflows. ### Standardizing External Voucher Integration - Developed a standardized technical framework to accommodate diverse external voucher issuers while maintaining a consistent and simple interface for the end-user. - Resolved technical trade-offs regarding API response speeds, error-handling policies, and real-time validation across disparate systems. - Empowered Product Managers to act as "technical translators" and "captains," proactively managing complex dependency chains and prioritizing core features over secondary improvements to meet delivery timelines. The successful integration of KakaoTalk vouchers demonstrates that overcoming platform silos requires more than just technical API mapping; it requires a fundamental shift toward user-centric thinking. By prioritizing the "seamlessness" of the connection over individual platform boundaries, organizations can unlock significant new growth opportunities and deliver a superior digital experience.

API DesignUser ExperienceProduct ManagementBackend+3

toss·Nov 27, 2025Original article

Toss Payments' Open API (opens in new tab)

Toss Payments treats its Open API not just as a communication tool, but as a long-term infrastructure designed to support over 200,000 merchants for decades. By focusing on resource-oriented design and developer experience, the platform ensures that its interfaces remain intuitive, consistent, and easy to maintain. This strategic approach prioritizes structural stability and clear communication over mere functionality, fostering a reliable ecosystem for both developers and businesses. ### Resource-Oriented Interface Design * The API follows a predictable path structure (e.g., `/v1/payments/{id}`) where the root indicates the version, followed by the domain and a unique identifier. * Request and response bodies utilize structured JSON with nested objects (like `card` or `cashReceipt`) to modularize data and reduce redundancy. * Consistency is maintained by reusing the same domain objects across different APIs, such as payment approval, inquiry, and cancellation, which minimizes the learning curve for external developers. * Data representation shifts from cryptic legacy codes (e.g., SC0010) to human-readable strings, supporting localization into multiple languages via the `Accept-Language` HTTP header. * Standardized error handling utilizes HTTP status codes paired with a JSON error object containing specific `code` and `message` fields, allowing developers to either display messages directly or implement custom logic. ### Asynchronous Communication via Webhooks * Webhooks are provided alongside standard APIs to handle asynchronous events where immediate responses are not possible, such as status changes in complex payment flows. * Event types are clearly categorized (e.g., `PAYMENT_STATUS_CHANGED`), and the payloads mirror the exact resource structures used in the REST APIs to simplify parsing. * The system ensures reliability by implementing an Exponential Backoff strategy for retries, preventing network congestion during recipient service outages. * A dedicated developer center allows merchants to register custom endpoints, monitor transmission history, and perform manual retries if automated attempts fail. ### External Ecosystem and Documentation Automation * Developer Experience (DX) is treated as the core metric for API quality, focusing on how quickly and efficiently a developer can integrate and operate the service. * To prevent the common issue of outdated manuals, Toss Payments uses a documentation automation system based on the OpenAPI Specification (OAS). * By utilizing libraries like `springdoc`, the platform automatically syncs the technical documentation with the actual server code, ensuring that parameters, schemas, and endpoints are always up-to-date and trustworthy. To ensure the longevity of a high-traffic Open API, organizations should prioritize automated documentation and resource-based consistency. Moving away from cryptic codes toward human-readable, localized data and providing robust asynchronous notification tools like webhooks are essential steps for building a developer-friendly infrastructure.

API DesignJsonRest ApiDeveloper Experience+4

naver·Nov 19, 2025Original article

Naver TV (opens in new tab)

JVM applications often suffer from initial latency spikes because the Just-In-Time (JIT) compiler requires a "warm-up" period to optimize frequently executed code into machine language. While traditional strategies rely on simulated API calls to trigger this optimization, these methods often introduce side effects like data pollution, log noise, and increased maintenance overhead. This new approach advocates for a library-centric warm-up that targets core execution paths and dependencies directly, ensuring high performance from the first real request without the risks of full-scale API simulation. ### Limitations of Traditional API-Based Warm-up * **Data and State Pollution:** Simulated API calls can inadvertently trigger database writes, send notifications, or pollute analytics data, requiring complex logic to bypass these side effects. * **Maintenance Burden:** As business logic and API signatures change, developers must constantly update the warm-up scripts or "dummy" requests to match the current application state. * **Operational Risk:** Relying on external dependencies or complex internal services during the warm-up phase can lead to deployment failures if the mock environment is not perfectly aligned with production. ### The Library-Centric Warm-up Strategy * **Targeted Optimization:** Instead of hitting the entry-point controllers, the focus shifts to warming up heavy third-party libraries and internal utility classes (e.g., JSON parsers, encryption modules, and DB drivers). * **Internal Execution Path:** By directly invoking methods within the application's service or infrastructure layer during the startup phase, the JIT compiler can reach "Tier 4" (C2) optimization for critical code blocks. * **Decoupled Logic:** Because the warm-up targets underlying libraries rather than specific business endpoints, the logic remains stable even when the high-level API changes. ### Implementation and Performance Verification * **Reflection and Hooks:** The implementation uses application startup hooks to execute intensive code paths, ensuring the JVM is "hot" before the load balancer begins directing traffic to the instance. * **JIT Compilation Monitoring:** Success is measured by tracking the number of JIT-compiled methods and the time taken to reach a stable state, specifically targeting the reduction of "cold" execution time. * **Latency Improvements:** Empirical data shows a significant reduction in P99 latency during the first few minutes of deployment, as the most CPU-intensive library functions are already pre-optimized. ### Advantages and Practical Constraints * **Safer Deployments:** Removing the need for simulated network requests makes the deployment process more robust and prevents accidental side effects in downstream systems. * **Granular Control:** Developers can selectively warm up only the most performance-sensitive parts of the application, saving startup time compared to a full-system simulation. * **Incomplete Path Coverage:** A primary limitation is that library-only warming may miss specific branch optimizations that occur only during full end-to-end request processing. To achieve the best balance between safety and performance, engineering teams should prioritize warming up shared infrastructure libraries and high-overhead utilities. While it may not cover 100% of the application's execution paths, a library-based approach provides a more maintainable and lower-risk foundation for JVM performance tuning than traditional request-based methods.

API DesignPerformance OptimizationJavaJvm+3

airbnb·Sep 15, 2025·4 min readCurated summary

Viaduct, Five Years On: Modernizing the Data-Oriented Service Mesh

Viaduct, Airbnb’s data-oriented service mesh, has evolved substantially over five years while retaining its core model: a central schema, hosted business logic, and re-entrant composition through GraphQL. Its usage has grown eightfold, supporting more than 130 teams and over 1.5 million lines of production code, without increasing operational overhead. Viaduct Modern now aims to simplify its developer API and establish stronger architectural boundaries, alongside the project’s release as open source. ## Adoption and Evolution - Viaduct traffic has increased by a factor of eight since 2020. - More than 130 teams now host code in Viaduct, supported by hundreds of weekly active developers. - The hosted codebase has grown to over 1.5 million lines, with roughly the same amount of test code. - Operational overhead has remained constant, incident-minutes have been cut in half, and costs have grown linearly with QPS. - Viaduct is now available as open-source software. ## Core Principles That Remain - **Central schema:** Viaduct provides one integrated schema connecting domains across Airbnb. - More than 75% of requests are internal. - The schema is developed by many teams but exposed as a connected graph. - **Hosted business logic:** Teams run business logic directly in Viaduct rather than maintaining separate microservices. - This reduces operational overhead and can allow standalone services to be retired. - Viaduct provides a serverless environment so developers can focus on application logic. - **Re-entrancy:** Hosted logic composes with other hosted logic through GraphQL fragments and queries. - This supports modularity. - It helps avoid the tightly coupled structure and maintenance problems associated with traditional monoliths. ## Problems with the Earlier Design - Viaduct’s APIs evolved reactively in response to individual use cases. - Multiple mechanisms emerged for accomplishing similar tasks, creating confusion for developers. - Some capabilities were well supported while others were not. - The framework’s layers had loose, inconsistent interfaces. - The boundary between Viaduct and hosted application code was weak. - These issues made framework improvements increasingly risky because changes could disrupt existing users. ## Simplifying the Tenant API - Viaduct Modern overhauls the developer-facing API and execution engine. - The new Tenant API reduces the implementation choices to two mechanisms: - **Node resolvers** - **Field resolvers** - The choice is determined by the schema rather than by ad hoc behavioral distinctions. - Resolver APIs have been unified wherever possible. - The goal is a smaller, more consistent surface that preserves successful ideas from the old API while removing unnecessary alternatives. ## Tenant Modules and Re-Entrant Composition - Viaduct uses modules and re-entrancy to provide boundaries similar to service definitions and RPC APIs in microservice architectures. - A tenant module combines: - Schema owned by a team - The code implementing that schema - Modules can create rich connections in the shared graph, but direct code dependencies between teams are discouraged. - Instead, teams declare their data requirements through GraphQL fragments and queries. ### Example: Extending the `User` Type - A Core User team owns the base `User` type and resolves fields such as `firstName` and `lastName`. - A Messaging team can extend `User` with a `displayName` field. - Its resolver declares that it needs `firstName` and `lastName`. - Messaging does not depend directly on Core User’s implementation or need to know where those fields originate. - This declarative model lets teams collaborate through the schema while preserving ownership and modularity. ## Framework Modularity - Viaduct Modern also restructures the framework itself. - The system consists of: - The GraphQL execution engine - The Tenant API - Hosted application code - Historically, the interfaces between these layers were weak, making performance and reliability improvements difficult to introduce safely. - The redesign focuses on stronger abstraction boundaries so the framework can evolve independently of application code. Viaduct’s modernization is intended to preserve its centralized, data-oriented model while making development simpler and framework evolution safer. The open-source release provides an opportunity for other organizations to evaluate or adopt this approach to schema-driven, modular service composition.

Read original(opens in new tab)

API DesignDistributed SystemsServerlessMicroservices+3

datadog·Sep 29, 2022·3 min readCurated summary

DRUIDS, the design system that powers Datadog

Datadog created DRUIDS in 2018 to provide consistent UX patterns across its rapidly expanding observability platform. The system succeeds only if designers and developers trust and use it, so its documentation and tooling are designed to be easy to understand, implement, and contribute to. Datadog’s approach connects design, source code, documentation, and development workflows into a shared source of truth. ## Easy to Understand ### Fast Navigation and Discovery - The DRUIDS documentation supports Cmd+K (or Ctrl+K) quick navigation for finding components, patterns, icons, logos, and other resources. - The “DRUIDS Loupe” lets Datadog employees inspect components directly on product pages. - Hovering over an inspected component reveals links to its source code, Figma files, and documentation. ### Connected Documentation - Component pages link to GitHub, Figma, and VS Code. - JSDoc comments provide descriptions and links back to DRUIDS documentation inside VS Code. - Figma also links back to relevant components and guidance. - These connections minimize dead ends and keep supporting context close to where people are working. ## Easy to Implement ### Editable Playgrounds - DRUIDS treats React, TypeScript, and CSS implementation as the source of truth because code defines the actual browser experience. - Interactive playgrounds let users explore component props, test variations, and copy production-ready code. - A Code Sandbox page allows multiple components to be combined into live prototypes. - Stateful internal URLs make it easier to share ideas and reproduce bugs. - The tools also help teams without dedicated frontend specialists build internal applications using familiar Datadog patterns. ### Auto-Generated API Documentation - Each component includes an API table listing its props, allowed values, and descriptions. - The tables are generated directly from source code rather than maintained separately. - This prevents documentation from drifting away from the implementation across more than 150 components. - Clear, meaningful prop names improve predictability for both designers and developers. ## Easy to Contribute Back ### Contribution Guidelines - DRUIDS is intended to evolve as Datadog’s products and customer needs change. - Internal contribution guidelines define expectations for core design, structure, prop naming, documentation, styling, responsiveness, accessibility, and testing. - The guidelines aim to reinforce quality without making contributions burdensome or intimidating. ### CLI Tooling - A command-line wizard generates the standard structure for new components, including code, tests, and documentation examples. - For example, `yarn component button` creates the scaffolding for a button component. - Automating boilerplate lets contributors focus on design, user experience, and performance. Datadog’s central recommendation is to treat a design system as more than a component library: it should connect users, designers, and developers through consistent patterns, live examples, source-linked documentation, and lightweight contribution workflows.

Read original(opens in new tab)

API DesignFigmaUser ExperienceReact+4

figma·Jun 10, 2019·2 min readCurated summary

Plugins are coming to Figma | Figma Blog

Figma announced the beta of its plugin platform, inviting developers to build tools that extend and improve design workflows. The initiative follows the success of Figma’s HTTP API and aims to make plugins powerful while preserving platform stability, security, performance, and compatibility. Figma initially planned a limited beta, with broader access and community-created plugins to follow. ## Opening the Figma Platform - Figma had previously launched an HTTP-based API for exporting design data and connecting Figma with other tools. - Customers used the API to: - Export icons through custom Slack commands. - Push design updates into development environments. - Maintain and distribute GitHub’s Octicons SVG library. - Independent designers and developers had also begun creating spaces for sharing Figma-related functionality. ## Designing a Stable Plugin System Figma recognized that plugins can create compatibility, security, and performance challenges. Rather than exposing internal APIs—which may change frequently—it designed dedicated third-party APIs intended to remain stable as Figma evolves. The company established several principles: - Plugins should be intuitive for all designers. - Anyone capable of building a website should be able to create a plugin. - Developers should be able to use popular programming languages. - Plugins should not harm Figma’s performance or user experience. - Figma would fully support and maintain the APIs used by plugins. ## What Plugins Could Do During the beta, developers could create plugins to: - Automate repetitive design tasks. - Speed up design workflows. - Import real-world data into Figma files. - Share plugins with teammates. Because Figma is web-based, the company expected plugins to be relatively easy to build and maintain for developers familiar with HTML and JavaScript. ## Beta Access and Future Availability - The beta was limited to a selected group of users. - Applicants were prioritized based on the ideas they wanted to build. - Figma intended to use the beta to stress-test and refine its plugin APIs. - Broader access was planned for the future. - Non-coders would eventually be able to use community-built plugins. Developers with basic web-development skills and a plugin idea were encouraged to apply for the beta.

Read original(opens in new tab)

API DesignJavaScriptWeb DevelopmentHTML+2