Slide 1

Slide 1 text

Is the monolith a problem? Chikahiro Tokoro

Slide 2

Slide 2 text

The monolith was blamed for last decade… Not scalable Complex and hard to debug Deployment bottleneck Not clear boundary Difficult to maintain

Slide 3

Slide 3 text

The monolith was blamed for last decade… Not scalable Not clear boundary Difficult to maintain Deployment bottleneck Complex and hard to debug

Slide 4

Slide 4 text

….and is the microservices a solution? ✅

Slide 5

Slide 5 text

Tobi Lutke (Shopify co-founder) - X Is the monolith, not scalable?

Slide 6

Slide 6 text

Is the monolith, deployment bottleneck? Interpreters Everywhere and All the Time - Stefan Marr, PLISS 2023

Slide 7

Slide 7 text

And Is the microservices, simple and easy to maintain?

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

BBC NEWS | UK | Magazine | The life cycle of a fashion trend

Slide 10

Slide 10 text

2014 2025 2004 1998

Slide 11

Slide 11 text

Macro trends in the tech industry | April 2024 | Thoughtworks

Slide 12

Slide 12 text

Freedom Dumlao on X - 2024.09 Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% - 2023

Slide 13

Slide 13 text

2025 rails, ruby - Explore - Google Trends

Slide 14

Slide 14 text

rails, spring, nextjs, django, laravel - Explore - Google Trends 2025

Slide 15

Slide 15 text

Monolith / Microservices are the architectures which has own pros and cons

Slide 16

Slide 16 text

CI / Deployment Language Monolingual Multilingual Slow Fast Simple Complex Infrastructure Latency Tracing Scaling Boundary Low High Single instance Multiple instances Clear Vague scale up (vertical) high cost, limited, simple scale out (horizontal) low cost, unlimited, complex

Slide 17

Slide 17 text

Monday 3-2-1 Conway's law - refactoring.fm Microservices can be more related for autonomy / scalability of organization

Slide 18

Slide 18 text

Building Microservices, 2nd Edition - Sam Newman: 1. What Are Microservices? - Should I Use Microservices? 2000 engineers, 2 millions lines of code: the history of a Rails monolith - Cristian and Anatoly | EuRuKo 2024

Slide 19

Slide 19 text

Method call API call which can be failed 😱 Circuit Breaker Retry mechanism In order to use another component… Is it essential complexity? (never failed)

Slide 20

Slide 20 text

Is the monolith a problem? No Then what’s the problem?

Slide 21

Slide 21 text

Jason Warner (Github ex-CTO) - X

Slide 22

Slide 22 text

Modular Monolith

Slide 23

Slide 23 text

What’s the modular monolith? InfoQ: Monolith Decomposition Patterns - Sam Newman

Slide 24

Slide 24 text

Shopify/packwerk: Good things come in small packages

Slide 25

Slide 25 text

2014 2025 2004 1998 Macro trends in the tech industry | April 2024 | Thoughtworks Modular Monolith

Slide 26

Slide 26 text

2014 2025 2004 1998 Macro trends in the tech industry | April 2024 | Thoughtworks Modular Monolith

Slide 27

Slide 27 text

Eileen Uchitelle - The Myth of the Modular Monolith - Rails World 2024

Slide 28

Slide 28 text

High cohesion is necessary

Slide 29

Slide 29 text

God Object

Slide 30

Slide 30 text

This is a problem! God Object

Slide 31

Slide 31 text

Tight coupling / Poor cohesion Antipattern: Single object knows/does too much What’s the God Object (Class) ? Hard to change, buggy Not clear boundary / Tangling e.g. Changing User Registration logic break Payment feature 😱 (violating Open/Closed Principle) Ball of Mud

Slide 32

Slide 32 text

Example of God Object

Slide 33

Slide 33 text

Not scalable Deployment bottleneck ✅ ✅ The monolith was blamed for last decade… Difficult to maintain Complex and hard to debug Not clear boundary

Slide 34

Slide 34 text

Not scalable Deployment bottleneck ✅ Those are characteristics of God Object! The monolith was blamed for last decade… Difficult to maintain Complex and hard to debug Not clear boundary

Slide 35

Slide 35 text

Distributed Monolith

Slide 36

Slide 36 text

2. Refactoring God Object 1. Better Model Design Where the God Object come from?

Slide 37

Slide 37 text

DRY ~ Don’t Repeat Yourself ~ “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.“ NOT for the code!! 1. Better Model Design

Slide 38

Slide 38 text

Invoice Receipt Customer understand DRY Let’s DRY for duplicated code!!

Slide 39

Slide 39 text

understand DRY Customer Document type: invoice / receipt Invoice Receipt Receipt is issued after invoice was paid use STI

Slide 40

Slide 40 text

understand DRY Customer Invoice Receipt Invoice can only be issued for company Document type: invoice / receipt

Slide 41

Slide 41 text

understand DRY Customer Invoice Receipt Company After issuing invoice, it should generate PDF Document type: invoice / receipt

Slide 42

Slide 42 text

Document type: invoice / receipt understand DRY Customer Invoice Receipt Company pdf

Slide 43

Slide 43 text

understand DRY Customer Invoice Receipt Company pdf Document type: invoice / receipt

Slide 44

Slide 44 text

understand DRY Invoice Receipt Customer This is a similarity! Code duplication might be coincident Invoice and Receipt are different (domain) knowledge

Slide 45

Slide 45 text

understand DRY Customer Invoice Receipt Company pdf

Slide 46

Slide 46 text

Customer Invoice Receipt Company pdf Document type: invoice / receipt Customer Invoice Receipt Company pdf Modularity / Cohesion / (Domain) Boundary may appear naturally

Slide 47

Slide 47 text

DRY is about Knowledge | Mathias Verraes DRY + Domain-Driven Design 1. Better Model Design

Slide 48

Slide 48 text

1. Better Model Design

Slide 49

Slide 49 text

User type: admin/customer/seller Admin Customer Seller Mixed model 1. Better Model Design

Slide 50

Slide 50 text

Article status: draft / scheduled / published Author Author DraftArticle Article Schedule Mixed model 1. Better Model Design

Slide 51

Slide 51 text

Order status: accepted / shipped Product Customer Domain crossing model Order Product Customer Shipment 1. Better Model Design

Slide 52

Slide 52 text

2. Refactoring God Object 1. Better Model Design

Slide 53

Slide 53 text

Go with clear business merit Don’t underestimate, It takes time!!

Slide 54

Slide 54 text

Example: User Single Sign-On User type: admin/customer/seller User Application A New Application B

Slide 55

Slide 55 text

Example: User Single Sign-On User type: admin/customer/seller Application A UserAuth User New Application B

Slide 56

Slide 56 text

User Single Sign-On UserAuth Auth Engine Application A Example: User User New Application B

Slide 57

Slide 57 text

User Single Sign-On UserAuth Auth Engine Application A Example: User User New Application B

Slide 58

Slide 58 text

User Single Sign-On UserAuth Auth Engine Application A Example: User User New Application B

Slide 59

Slide 59 text

Example: Order … Order status: new / ordered / paid / fulfilled / shipping / finished Order cannot track multiple Shipments Mixing Domains: Process / Payment / Fulfillment / Shipment Changing Order needs re-Payment Order Shipment Shipment Shipment Basket Payment Order Related Order needs another Order 2. Refactoring God Object etc….

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

Is your Software Ready for the Next Build? – Webomates

Slide 62

Slide 62 text

Order status: new / ordered / paid / fulfilled / shipping / finished Shipment Shipment Shipment Order status: new / ordered / paid / fulfilled Track multiple Shipments No need to re-payment Make multiple Orders Order Shipment Shipment Shipment Basket Payment Order Shipment Shipment Shipment Order status: paid / fulfilled Basket Order status: paid / fulfilled 2. Refactoring God Object

Slide 63

Slide 63 text

Example: Order can track multiple Shipments Order status: new / ordered / paid / fulfilled / shipping / finished Shipment Shipment Shipment Order status: new / ordered / paid / fulfilled

Slide 64

Slide 64 text

Strangler Fig Pattern - Martin Fowler The Big Bang | Creating Software - A Sisyphean Task?

Slide 65

Slide 65 text

Refactoring Legacy Code with the Strangler Fig Pattern - Shopify

Slide 66

Slide 66 text

Is the monolith a problem? No The problem is often “God Object” there is a tendency to blame the technology the issue of modeling

Slide 67

Slide 67 text

1. North star modeling: DRY + DDD To fix “God Object” 2. Refactoring: Incremental release with business merit Feature Flag (Canary release) Shadow Traffic (Parallel adoption) Strangler Fig (Phased implementation)

Slide 68

Slide 68 text

Thank you! Let’s have a chat! https://chikahirotokoro.com/ Chikahiro

Slide 69

Slide 69 text

one more thing…

Slide 70

Slide 70 text

Matz came to my podcast guest! 🤯 (japanese)

Slide 71

Slide 71 text

https://en.kaigaiiju.ch Just released English (AI) translated episodes of Matz! Living Overseas