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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2023 Reiwa Travel, Inc.  Proﬁle ● 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

Slide 3

Slide 3 text

令和トラベル‧NEWTについて Information 1.

Slide 4

Slide 4 text

社名株式会社令和トラベル代表者篠塚孝哉創業 2021年4⽉5⽇従業員 100名（役員‧正社員）※2024年5⽉1⽇時点登録番号観光庁⻑官登録旅⾏業第2123号資本⾦ 70.2億円 (資本剰余⾦を含む）会社概要 About Us

Slide 5

Slide 5 text

シリーズAラウンドにて48億円の資⾦調達を実施 Series A funding round テクノロジー分野への投資を加速し、グローバル展開へ。シリーズAの資⾦調達により、さらに⼤胆に技術投資を⾏い、最先端テクノロジーを活⽤し、デバイスに最適化した最⾼のユーザビリティーの実現、個⼈に合わせた情報提供など、これまでの旅のスタイルを根底から変えていく挑戦を加速。さらに、今後、国内旅⾏事業、フライト予約機能、グローバル展開と事業ポートフォリオを拡⼤予定。

Slide 6

Slide 6 text

あたらしい旅⾏を、デザインする。私たちは旅⾏が⼈⽣を豊かにしてくれると信じている。デジタルの⼒を活⽤し、よりあたらしい旅⾏体験へとアップデートしていくことが、私たちの使命であり挑戦である。ミッション Mission

Slide 7

Slide 7 text

事業⽅針‧計画 Our Business Plan ツアーから始まり、ホテル、エアー、グループ旅⾏と事業ポートフォリオを拡⼤予定。テクノロジーを活⽤し、すべての旅⾏に対応するデジタルトラベルエージェンシーを⽬指しています。

Slide 8

Slide 8 text

事業⽅針‧計画 Our Business Plan 事業ポートフォリオの拡⼤と並⾏し、マーケットのターゲットを広げることで、事業の規模を伸ばしていきます。

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

私たちのサービス Our Service 海外ツアー予約宿‧ホテル予約 (ホテル + 航空券セット) 旅⾏ガイドトラベルコンシェルジュグループトラベル ‧修学旅⾏ ‧企業の研修旅⾏などかんたん‧おトク‧えらべる‧あんしんな旅⾏の提供 ‧旅⾏相談 ‧VIP対応

Slide 11

Slide 11 text

海外ツアー予約 Overseas Tour Reservations ⼤⼿ECサイトでミネラルウォーターを買うくらい「かんたん」に海外旅⾏を予約煩雑になりがちな海外旅⾏予約を、直感的なUI/UXでストレスフリーなサービス設計

Slide 12

Slide 12 text

海外ツアー予約 Overseas Tour Reservations 予約のスマート管理旅程表やチケットはすべてアプリにやることリスト出発前の準備もばっちりパスポートスキャントラベルリンク同⾏者のアプリに予約をリンク煩雑な旅⾏準備もアプリで完結パスポートはカメラで読みとり

Slide 13

Slide 13 text

⼀緒にチャレンジしてくれる仲間を募集中！ We Want Co-Workers Who Will Take on A Challenge with Us!

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

NEWT Tech stack

Slide 18

Slide 18 text

NEWT Tech stack

Slide 19

Slide 19 text

NEWT Tech stack

Slide 20

Slide 20 text

NEWT Tech stack

Slide 21

Slide 21 text

NEWT Tech stack

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Challenge ① : Multiple Products We scaled from one product to multiple products

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

We scaled from one backend team to multiple backend teams per product Challenge ② : Multiple Backend Teams

Slide 32

Slide 32 text

Challenge ② : Multiple Backend Teams Even separating members in teams for each product, the code was not allowing this isolation & flexibility

Slide 33

Slide 33 text

Modules were depending heavily on each other Challenge ② : Multiple Backend Teams

Slide 34

Slide 34 text

Modules were depending heavily on each other Challenge ② : Multiple Backend Teams

Slide 35

Slide 35 text

A small change in one module affects others and Increased risk of breaking unrelated parts of the system. Challenge ② : Multiple Backend Teams

Slide 36

Slide 36 text

Cycle Dependencies Challenge ② : Multiple Backend Teams

Slide 37

Slide 37 text

Cycle Dependencies Challenge ② : Multiple Backend Teams

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Slide 48

Slide 48 text

● 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

Slide 49

Slide 49 text

Communication flow using the shared layer Action ②：Shared Layer

Slide 50

Slide 50 text

If NEWT Tour team, need a functionality from NEWT Hotel team, that functionality need to be exposed in the shared layer Action ②：Shared Layer

Slide 51

Slide 51 text

Application Request Flow, also becomes simpler Action ②：Shared Layer

Slide 52

Slide 52 text

Slide 53

Slide 53 text

We introduced Clear Layers Action ③：Clear Layer + Coding Rules

Slide 54

Slide 54 text

We introduced Clear Layers Action ③：Clear Layer + Coding Rules

Slide 55

Slide 55 text

⚠ 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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

● 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

Slide 58

Slide 58 text

Slide 59

Slide 59 text

● 🧩 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 振り返り