Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scaling Fast with Confidence: Evolving NEWT’s B...

Scaling Fast with Confidence: Evolving NEWT’s Backend Code Architecture

At ReiwaTravel, we’re evolving NEWT’s backend code architecture to enable more independent teams, reduce complexity, and move faster. In this presentation, I’ll share how we’re structuring our TypeScript monorepo with clear layers, modular boundaries, and architectural patterns that improve maintainability, reduce conflicts, and support long-term scalability—even as the team grows and features multiply.

Avatar for Rodrigo Ramirez

Rodrigo Ramirez

May 20, 2025
Tweet

More Decks by Rodrigo Ramirez

Other Decks in Programming

Transcript

  1. © 2023 Reiwa Travel, Inc.
 Profile • Nationality: Argentinian •

    Language: Spanish, English, Japanese • Full Stack Developer (+10y) Career • 󰎆 2006~: Freelance • 󰎆 2008~: PowerSite ( CTO/CEO ) ◦ Email Marketing SaaS • 󰏦 2015~: Travelience ( CTO ) ◦ Tour Guide Marketplace • 󰏦 2021~: ReiwaTravel ( Senior Engineer ) Senior Engineer / Product-Dev Rodrigo Ramirez
  2. 社名 株式会社令和トラベル 代表者 篠塚 孝哉 創業 2021年4⽉5⽇ 従業員 100名(役員‧正社員)※2024年5⽉1⽇時点 登録番号

    観光庁⻑官登録旅⾏業第2123号 資本⾦ 70.2億円 (資本剰余⾦を含む) 会社概要 About Us
  3. 私たちのサービス Our Service 海外ツアー予約 宿‧ホテル予約 (ホテル + 航空券セット) 旅⾏ ガイド

    トラベル コンシェルジュ グループトラベル ‧修学旅⾏  ‧企業の研修旅⾏など かんたん‧おトク‧えらべる‧あんしんな旅⾏の提供 ‧旅⾏相談 ‧VIP対応
  4. AGENDA
 © 2023 Reiwa Travel, Inc.
 1. Context: How we

    started 2. Problem: What challenges we are facing 3. Action: What we are doing to solve them
  5. Backend API We started as a Modular Monolith • We

    have some base rules about how to structure each module • We provided freedom to developers to quickly ship features ├ 📁modules │ ├ 📁module-A │ ├ 📁module-B │ └ 📁… └ 📄server.ts
  6. Backend API We started as a Modular Monolith • We

    have some base rules about how to structure each module • We provided freedom to developers to quickly ship features ├ 📁modules │ ├ 📁module-A │ ├ 📁module-B │ └ 📁… └ 📄server.ts The first years everything was good, until we start growing in products, team members, users… ⚠
  7. Challenge ① : Multiple Products New Products Development, needed to

    share existing code, so we just treated them as a module, since at the beginning, new products were PoCs, min investment to deliver
  8. Challenge ① : Multiple Products During PoC was ok, but

    more and more features were needed, and these Product modules started to be big
  9. Challenge ① : Multiple Products During PoC was ok, but

    more and more features were needed, and these Product modules started to be big
  10. We scaled from one backend team to multiple backend teams

    per product Challenge ② : Multiple Backend Teams
  11. Challenge ② : Multiple Backend Teams Even separating members in

    teams for each product, the code was not allowing this isolation & flexibility
  12. A small change in one module affects others and Increased

    risk of breaking unrelated parts of the system. Challenge ② : Multiple Backend Teams
  13. These challenges can be summarized in the following issues •

    Dependency issues ◦ Modules depending heavily on each other ◦ A small change in one module affects others ◦ Increased risk of breaking unrelated parts of the system • Code Complexity ◦ Code that is difficult to understand or navigate ◦ Developers need to know too much before making a change ◦ Hard to onboard new members ◦ Debugging and maintenance take longer Summary
  14. © 2023 Reiwa Travel, Inc.
 🧠 The turning point How

    can we scale faster and with confidence?
  15. Context • We need to make NEWT Global and expand

    what each product can do • We need to increase the backend team members to achieve this 🧠 The turning point
  16. Our Goals • Create isolated teams • Reduce the complexity

    of our system/code • Allow engineers to make changes with confidence • Onboard new members faster • Prepare our code to scale 🧠 The turning point
  17. © 2023 Reiwa Travel, Inc.
 Action ① We moved from

    Modular Monolith to Modular Monolith Monorepo
  18. To support the scale of products, teams and maximize the

    reutilization of our current logic We moved from Modular Monolith to Modular Monolith Monorepo Action ①:Modular Monolith Monorepo
  19. We changed the directory structure to a typical TypeScript monorepo

    ├ 📁modules │ ├ 📁module-A │ ├ 📁module-B │ └ 📁… └ 📄server.ts ├ 📁apps │ ├ 📁app-A │ └ 📁app-B └ 📁packages ├ 📁package-A ├ 📁package-B └ 📁core Before After Action ①:Modular Monolith Monorepo
  20. Moved legacy code inside one of the apps and incrementally

    migrate it ├ 📁modules │ ├ 📁module-A │ ├ 📁module-B │ └ 📁… └ 📄server.ts ├ 📁apps │ ├ 📁app-A │ └ 📁app-B └ 📁packages ├ 📁package-A ├ 📁package-B └ 📁core Before After Action ①:Modular Monolith Monorepo
  21. © 2023 Reiwa Travel, Inc.
 Action ② To control Dependencies

    issues, we introduced a Shared Layer & Service Contracts
  22. • Files inside the shared layer can be imported from

    outside modules • We have a public Service class (Facade) that provide functionality with a easy to understand interface (contract) hiding complexity Action ②:Shared Layer
  23. If NEWT Tour team, need a functionality from NEWT Hotel

    team, that functionality need to be exposed in the shared layer Action ②:Shared Layer
  24. © 2023 Reiwa Travel, Inc.
 Action ③ To reduce Code

    Complexity We introduced Clear Layers + Coding Rules
  25. ⚠ About Rules! • Too many rules and structure can

    increase complexity • While implementing we discussed with team members to simplify layers, process • We agreed which parts of the system we wanted to protect and provide flexibility in other areas • Linters warning us about wrong usage • We used AI Agents rules to generate most of the code Action ③:Clear Layer + Coding Rules
  26. • We moved from Modular Monolith to Modular Monolith Monorepo

    • Each product area became an isolated context (Packages) • To reduce dependencies issues, we introduced a Shared Layer • To reduce code complexity we introduced Clear Layers and Coding Rules Summary of changes
  27. • 🧩 Don’t over-engineer early, but invest in structure before

    it hurts ◦ Refactoring code takes time, make decisions that helps to reduce this pain • 🥷 Build your system for all engineers ◦ Do not depend on specific individuals, all members should be able to make changes with confidence to any part of the system • 🤖 The future is AI-assisted, structure is your best investment ◦ Allow engineers to focus in what is important 振り返り