Good Design Pays Dividends: The Evolution of LINE API Gateway Handling 30B Daily Requests

30 billion requests per day. That's the scale of LINE's API Gateway after 15 years in production. As traffic grew, new challenges appeared. Latency in a single backend could affect the entire API layer. Adding even a simple API required code changes, and hundreds of API documents gradually drifted away from the implementation.

To solve these problems, we built Moon, an API Gateway framework based on declarative API specifications, asynchronous processing, and a plugin architecture. The result was 3× higher throughput per server and the ability to add APIs without restarting servers.

It wasn't just about performance. The same API specifications are now used for documentation, traffic-based validation, and AI tooling. This session covers the design of Moon and how solving infrastructure challenges opened the door to new capabilities.

Transcript

1. 2026.06.29 LY Corporation GIHWAN KIM | LINE Channel Platform YEJIN SHIN | LINE Channel Platform Good Design Pays Dividends: How LINE API Gateway Handles 30B Daily Requests
2. YEJIN SHIN | LINE Channel Platform GIHWAN KIM | LINE Channel Platform Speakers
3. About the LINE Channel Platform The Problems We Faced The Decision That Solved the Problem The Outcomes We Achieved 1 3 2 4 Agenda
4. LINE Channel Platform LINE Platform Profile Add friend Friend list Send message Channel Platform Services
5. Todayʼs Channel Numbers that frame this talk 30B requests per day 700+ APIs 15y In production 14M+ channels using us
6. 30B
7. What actually happened that day The problems, we faced
8. Performance & Reliability
9. Sync, blocking Happy path. requests 6 / 8 held 2 free one upstream Thread pool
10. Sync, blocking Runtime limits, one slow upstream cascades. requests Thread pool 8 / 8 held 0 free upstream (lagging) new request ❌ rejected because no threads free
11. Sync, blocking Single Point of Failure. whole pool held by A Client A Client B Client C ❌ ❌ upstream A (slow) upstream B (ok) upstream C (ok) Thread pool
12. Every API was written by hand.
13. The Gate Every new API also has to go through us.
14. A Slack message arrives Hi, team. Could you add Foo API for us? 🙏 Sure!
15. And then, more messages Hi, team. Could you add Foo API for us? 🙏 Sure! Could we set up a meeting? This API has business rules, sharing the domain spec 📎
16. Not over yet, We have to code it Have a meeting Write code Make tests Review & Merge Write docs Release
17. Three teams, three truths Dev Service Operation API API API API
18. Fix them one by one? Or one decision that closes them all? Our decision, in one line
19. Identify what the team doesn't need to do, and focus on what only we can do. Minimize our effort to add a new API
20. Specs instead of code
21. Single Source of Truth One Source Multi-Use YAML
22. Meet Moon Our declarative spec-driven API gateway framework.
23. What Moon was built for Moon Declarative behavior in YAML Dynamic no restart Extensible your own plugins High performance async on Armeria
24. gateway: routes: myApi: path: /api upstream: uri: https://line.me plugins: - type: LoggingPlugin The spec we wrote
25. gateway: routes: myApi: path: /api upstream: uri: https://line.me plugins: - type: LoggingPlugin The spec we wrote
26. Moon framework Define an API gateway in spec. Control Plane Central Dogma File System In memory Property Source RouteConfig ApiConfig UpstreamConfig PluginConfig HttpService WebClient Management Plane Data Plane Backend Services
27. Three building blocks Which request? Route/API matches the method + path Where to? Upstream the backend it forwards to What happens? Plugin behavior added on the way
28. Route A direct route is a leaf, a base route is a branch. routing table GET /health prefix:/api base route ̶ a branch GET /api/users POST /api/users GET /api/users/:id
29. Not just an endpoint, including more details. OpenAPI compatible: - Parameters - Request body - Responses API Base route prefix:/v1 Base route prefix:/v2 Get Profile v1 GET /v1/profile Get Profile v2 GET /v2/profile Send Message v1 POST /v1/message Profile Service (REST) Messaging Service (gRPC)
30. Upstream A response publisher. HTTP Forward to a backend (default). File Serve a static file without backend. Early-return Return a fixed response. index.html 200 { "ok": true } Sequential Call sub upstreams in order. B C Rolling-update Split old/new by ratio. old 80% new 20%
31. Reactive Streams, end to end A different D A T A chunk sits in each hop. Client Route (API) Upstream Backend D A T A Client HttpServer Route (API) Upstream Backend D A T A
32. Plugin Cross-cutting concerns as a decorator. request → auth security logging observability rate limit traffic transform shaping → → → → upstream
33. Plugins Resilience circuit breaker retry throttle Observability logging metrics tracing Transform mapping filtering validation Security auth CORS deduplication
34. Built-in expression language Evaluate conditions, transform data, and build dynamic behaviors declaratively. Use jq-style expressions for complex payload transformations. Plugins type: MappingHttpResponsePlugin rules: status: 200 rewrite: content: content-type: application/json content: | res.content().asJsonObject() | { message: .commit.message, name: .commit.committer.name }
35. Schema-based behavior Plugins can leverage schema metadata defined in the API specification. Apply cross-cutting concerns at the schema level. • Apply field-level encryption. • Sanitize sensitive information. • Validate requests and responses against the schema. API Plugin schema: type: object properties: id: type: string x-line-id-encryption: true name: type: string
36. How a YAML file becomes a gateway GitHub PR merged Central Dogma live mirror Moon orchestrates reconfigure Armeria config v1 config v2 Client Upstream
37. That was all of Moon Now, what does this look like to a human?
38. The same Slack message, again Hi, team. Could you add Foo API for us? 🙏 Could you make a PR?
39. Same messages, based on GitOps Make a PR Run tests Review & Merge Release, Documentation, AI learning
40. PR driven development PR #123 a spec change temporary live env spin up from the PR Test before deployment Preview API docs
41. Three harvests What changed first, what changed next, and what became possible.
42. First harvest What changed first
43. 3× throughput per server • Fully asynchronous on Armeria • No thread-per-request ceiling • No more cascading failure
44. No more cascading failure A B C Client A Client B Client C upstream A (slow) upstream B (ok) upstream C (ok)
45. Second harvest What changed next
46. API Reference from spec
47. Server Driven UI Row Column Segmented Buttons Card Column Markdown Code React
48. Three teams, one truth Dev Service Operation API API API API
49. What if forget to update the spec?
50. Eventually consistent Spec amount: integer Live traffic amount: "12.5" Mismatch detected Alert the owner Fix the spec Fix the implementation
51. Third harvest What became possible
52. Natural language API search
53. • Specs served over the MCP protocol • AI tools read our gateway directly • Structured = a low bar to entry MCP Server Support
54. What we learned
55. Structure Consistency Leverage Building systems
56. Thank you