Navigating the Pitfalls of Modern Tech Stacks: A Real-World DDD Journey in a Serverless World

In this talk, we’ll share our journey at Billy, a startup that embraced modern technologies like serverless architectures, microservices, and even blockchain (Yes we know… Nobody's perfect).. Despite the promise of reduced complexity, we encountered significant friction between our tech stack and business needs during a critical pivot. We’ll explore how architecture options, though designed to defer decisions, introduced excessive complexity, and discuss our strategies for aligning business and technology through bounded contexts, continuous delivery, and targeted refactoring.

Transcript

1. Navigating the Pitfalls of Modern Tech Stacks A Real-World DDD Journey in a Serverless World
2. Maria Mokbel Tech Lead Wassel Alazhar Systems Explorer Founder of Umans
3. What to expect?
4. What to expect? Startup Serverless Microservices Blockchain Domain-Driven Design (DDD) Complexity Friction Business Alignment Tech Pivot Lessons Learned Architecture Critical Pivot Simplicity vs Reality
5. What to expect? Startup Serverless Microservices Blockchain Domain-Driven Design (DDD) Complexity Friction Business Alignment Tech Pivot Lessons Learned Architecture Critical Pivot Simplicity vs Reality
6. Where it all began
7. Complexity Time This talk is about complexity over time
8. Complexity Time This talk is about complexity over time Business Domain Essential complexity
9. Complexity Time This talk is about complexity over time Business Domain Essential complexity “Easy” Reductionist solutions
10. Complexity Time This talk is about complexity over time Business Domain Essential complexity “Easy” Reductionist solutions Solution with DDD
11. Complexity Time This talk is about complexity over time Business Domain Essential complexity “Easy” Reductionist solutions Solution with DDD Solution with DDD + Learning Curve
12. Complexity Time “Easy” Reductionist solutions Business Domain Essential complexity Solution with DDD Solution with DDD + Learning Curve MVP Overdesign Accidental Complexity Technical / Modelling Debt Short term projects Long term projects This talk is about
13. Complexity Time “Easy” Reductionist solutions Business Domain Essential complexity Solution with DDD Solution with DDD + Learning Curve Short term projects Long term projects This talk is about The battle of a team to get from here to there
14. Time in Startup's World Complexity Time Reductionist solutions Business Domain Essential complexity Billy
15. • Created in 2022 • Based in Paris, France • The first pitch: a web3 ticketing platform ⛓🎫
16. ⏱ 6 months runway • Created in 2022 • Based in Paris, France • The first pitch: a web3 ticketing platform ⛓🎫
17. A short runway leads to aggressive shortcuts • MVP-first mindset • A lot of experimentations • Aggressive Shortcuts
18. A short runway leads to aggressive shortcuts • MVP-first mindset • A lot of experimentations • Aggressive Shortcuts Using CSV extracts to validate attendees' tickets Building tailored one-off web apps for each client with specific needs Using Grafana internally and externally for data visualization Some real life shortcuts examples:
19. Rapid experimentation #1 Ticket marketplace #2 Event creation #3 Access control app #4 NFTs drop tool The Product(s) The Team 󰸮🧑 2 Founders 󰢨󰠣 2 Developers "More Tech products than team members"
20. Our "Modern" Stack Serverless No-code/low-code solutions Microservices The Blockchain </>
21. Our (not so) "Modern" Stack so 2022 No LLM No AI Agent Serverless No-code/low-code solutions Microservices The Blockchain </>
22. Serverless The Promise: you do the code, the Cloud Provider does the rest! • Pay-for-use pricing • Seamless scalability: perfect match for our ticketing platform! • Less operational complexity: no capacity planning, securing OS and runtime…
23. Serverless + Chalice Framework The Promise: you do the code, we handle the cloud provider! • Familiar structure • Simplified deployments and packaging • Per-route observability • Simplified local testing Rest API Function-per-lambda
24. Microservices The Promise: ship fast while maintaining clear boundaries • Independent development lifecycles • Different tech stacks • Enhanced fault isolation Microservices deployed on lambdas
25. Low-code + CRUD Api The Promise: free features (And how to delay Back Office related decisions)
26. Blockchain • Collectible, long-lasting Tickets • Fraud prevention • Limit unfair re-selling The promise: a great business value
27. Consequences • Serverless => Pay as you go, Scale • Microservices => Independent delivery streams • Low-code => Ship fast • Blockchain => Seems like a good Business Value • And a lot of features => Fast testing of our ideas
28. Hidden Complexity & The Turning Point Complexity Time Reductionist solutions Business Domain Essential complexity Billy
29. ⏱ 6 months runway
30. ⏱ 6 more months runway
31. ⏱ …and 6 more months runway
32. ⏱ …and yet 6 more months runway
33. It’s been 24 months
34. Complexity Time It’s been 24 months Business Domain Essential complexity “Easy” Reductionist solutions The cost of shifting requirements Misalignment between evolving business needs and rigid tech structures causing accidental complexity to explode beyond essential complexity!
35. Early tech choices: Serverless, Microservices, No-code, Blockchain, And a lot of unwanted features
36. How did they backfire ?
37. But - Cold starts - Database related-performance issues - System Design "heavy lifting" Serverless The promise You do the code, the Cloud Provider does the rest!
38. But - Locked-in to the framework (which is hardly maintained), no portability - Complicated Living documentation Serverless + Chalice Framework The promise The Promise: you do the code, we handle the cloud provider! Chalice
39. But - Too many deployment units - More than 7 CI/CD (3 techs 👤)! - The maintenance overhead was overwhelming. Microservices The promise Ship fast while maintaining clear boundaries 🚀 🚀
40. But - Lack of customization - A production environment only and no version control! - Giving access to a CRUD Api to Event Organizers generated bugs! Low-code + CRUD Api The promise Free features!
41. But It's an evolving unstable ecosystem and the maintenance overhead is massive. Blockchain The promise A great business value! The status of the Polygon API we were using
42. But Significant UX complexity Blockchain The promise A great business value! Example: how could people sell their tickets (NFTs) without having them approving the blockchain transaction?
43. But Significant costs: every smart contract deployment or NFT-related transaction requires gas fees. Blockchain The promise A great business value!
44. Consequences • A lot of experimentations = A lot of unwanted features shipped • Maintenance overhead was overwhelming for a team of 3 • Simplistic solutions started to backfire with an increasing number of bugs
45. Good news: We survived!
46. Good News: We survived From a Web3 ticketing platform to a White Label Event Store ⏱ 36 more months
47. Good News: We survived From a Web3 ticketing platform to a White Label Event Store ⏱ 36 more months without Blockchain
48. Bad news: Complexity is holding us back
49. The Breakthrough From buying single tickets or tickets within bundles… …To buying single products and modify the tickets pricing inside a bundle Nearly impossible to develop this new feature !
50. The Breakthrough From buying single tickets or tickets within bundles… …To buying single products and modify the tickets pricing inside a bundle Nearly impossible to develop this new feature ! Let's throw the model !
51. Let's pull down the red line! Complexity Time Reductionist solutions Business Domain Essential complexity Billy
52. Let's pull down the red line! Complexity Time Business Domain Essential complexity Reductionist solutions Billy Domain-Driven Solutions
53. Fake it till you make it Let's pull down the red line! Complexity Time Reductionist solutions Business Domain Essential complexity Billy Domain-Driven Solutions
54. Fake it till you make it When it is worth it, do it Well Let's pull down the red line! Complexity Time Reductionist solutions Business Domain Essential complexity Billy Domain-Driven Solutions
55. Step back on one critical feature: Bundles
56. Step back on one critical feature: Bundles
57. Step back on one critical feature: Bundles Experiment ticket-based bundles
58. Step back on one critical feature: Bundles Experiment ticket-based bundles Fake it!
59. - How to calculate availability? - How to apply time-based pricing? - How can one fulfillment process handle both digital ticket delivery and physical merchandise shipping? - How to manage bundle-only discounts? - How to handle bundle-specific rules? Challenges
60. - How to calculate availability? - How to apply time-based pricing? - How can one fulfillment process handle both digital ticket delivery and physical merchandise shipping? - How to manage bundle-only discounts? - How to handle bundle-specific rules? - How many if-else statements does it take before your product validation becomes unmaintainable? - How many nullable fields? Challenges
61. What is a bundle?
62. A container of products What is a bundle? Offering Defines What can be sold
63. A container of products A price that needs to be split What is a bundle? Offering Defines What can be sold Pricing Determines how much it costs
64. A container of products A single price multi item purchase A price that needs to be split What is a bundle? Offering Defines What can be sold Pricing Determines how much it costs Checkout Handles the purchase process
65. A container of products A single price multi item purchase A set of items that must be shipped together A price that needs to be split What is a bundle? Offering Defines What can be sold Pricing Determines how much it costs Checkout Handles the purchase process Fulfillment Delivers what was purchased
66. A container of products A single price multi item purchase A set of items that must be shipped together A price that needs to be split Distribution Channel What is a bundle? Context Specific Models Offering Defines What can be sold Inventory Manages what is available Pricing Determines how much it costs Checkout Handles the purchase process Fulfillment Delivers what was purchased Provides product definition Provides product structure Provides prices Check availability Create orders
67. Fake it till you make it When it is worth it, do it Well Let's pull down the red line! Complexity Time Reductionist solutions Business Domain Essential complexity Billy Domain-Driven Solutions
68. Fake it till you make it When it is worth it, do it Well Let's pull down the red line! Complexity Time Reductionist solutions Business Domain Essential complexity Billy Domain-Driven Solutions 1. Agree on this
69. Fake it till you make it When it is worth it, do it Well Let's pull down the red line! Complexity Time Reductionist solutions Business Domain Essential complexity Billy Domain-Driven Solutions 1. Agree on this 2. Explore options
70. Fake it till you make it When it is worth it, do it Well Let's pull down the red line! Complexity Time Reductionist solutions Business Domain Essential complexity Billy Domain-Driven Solutions 1. Agree on this 2. Explore options 3. Start here Develop capabilities
71. Toolkit Source: https://github.com/ddd-crew/ddd-starter-modelling-process
72. Before the Tools, Ask the Question What problem are we trying to solve now?
73. Then - Prevent ticket fraud - Collectible NFTs - Resale marketplace From Hype to Focus Now Giving organizers better tools to engage fans and grow their brand
74. Make the implicit Explicit Understanding the (new) Business Model
75. Modeling > Model The process mattered more than the output.
76. Modeling > Model
77. Exploring problem space
78. Exploring Bounded Contexts
79. Exploring Bounded Contexts
80. Exploring Options
81. REST API Selected option to start DB External Systems Payment (Stripe) Seating (Seats.io) Shopping (Shopify) Messaging (Brevo)… MONOLAMBDALITH
82. REST API Distribution Selected option to start DB External Systems Payment (Stripe) Seating (Seats.io) Shopping (Shopify) Messaging (Brevo)… Offering Inventory Pricing Fulfillment Checkout MODULAR LAMBDALITH
83. Familiar architecture to deal with fuzzy boundaries
84. 1. Who calculates bundle prices when multiple discount types apply? 2. Who determines bundle availability with optional components? 3. Who decides which bundle components can be substituted? 4. Who handles partial fulfillment of bundles? 5. Who manages inventory shared across multiple bundles? 6. Who coordinates mixed digital/physical bundle communications? 7. Who validates component compatibility within bundles? 8. Who processes partial bundle refunds? 9. Who allocates revenue across bundle components? 10. Who suggests bundle upgrades during checkout? Fuzzy boundaries REST API
85. Complexity shift Before: A single, large, complex domain model that becomes increasingly difficult to understand, maintain, and evolve. After: Multiple smaller, focused domain models (Bounded Contexts) with clearer boundaries and responsibilities. REST API The complexity hasn't disappeared. It has shifted: - We've reduced the complexity of each individual model - We've introduced a new type of complexity: managing the relationships between contexts
86. Complexity shift REST API The complexity hasn't disappeared. It has shifted: - We've reduced the complexity of each individual model - We've introduced a new type of complexity: managing the relationships between contexts Exploring interactions with Domain Message Flow Modelling
87. Complexity shift REST API The complexity hasn't disappeared. It has shifted: - We've reduced the complexity of each individual model - We've introduced a new type of complexity: managing the relationships between contexts Exploring interactions with Event Modelling
88. Complexity shift The trade-off: - The integration complexity is still more manageable than a single massive model - Smaller, more coherent models - Changes in one context have controlled impact on others - The ubiquitous language can be more precise within each context REST API The complexity hasn't disappeared. It has shifted: - We've reduced the complexity of each individual model - We've introduced a new type of complexity: managing the relationships between contexts
89. Complexity shift Source: The Serverless Illusion, Gregor Hohpe
90. Major pitfall Introducing a tool or technology will not be enough to reduce complexity. None of these will: - Bounded Contexts - Serverless - Microservices - Event-Sourcing / CQRS - Agentic AI Whenever humans are involved maintaining a system, the bottleneck will be: the learning curve
91. Major pitfall Complexity Time Business Domain Essential complexity Reductionist solutions Billy Domain-Driven Solutions
92. Major pitfall Complexity Time Reductionist solutions Business Domain Essential complexity Domain-Driven Solutions + Learning Curve Billy We’d rather not go there Domain-Driven Solutions
93. Let's pull down the red line! The Gap Between Knowing and Moving Top 3 of what worked for us: 1. Unship! 2. Develop continuous delivery capabilities 3. Start with familiar concepts and incrementally introduce patterns
94. Unship Taking benefits from our past learnings “Excessive complexity is nature’s punishment for organizations that are unable to make decisions.” Gregor’s Law
95. Unship Taking benefits from our past learnings “Excessive complexity is nature’s punishment for organizations that are unable to make decisions.” Gregor’s Law Experiments Learnings Decisions Reduced Complexity
96. Why unshipping is hard? - Delivering value by removing features - It is still work to do
97. Build Capabilities, Not Just Features Continuous Delivery Continuous delivery is not optional for evolutionary architecture. Single team → single reliable pipeline Auto-documented Makefiles DB Migrations
98. LEGACY Continuous Delivery Don’t Tunnel. Pivot In The Open - Double run to de-risk Rebuild incrementally. In production. With feedback Brand new modular lambdalith External Systems Payment (Stripe) Seating (Seats.io) Shopping (Shopify) Messaging (Brevo)… Ticketing Marketplace UI
99. LEGACY Continuous Delivery Don’t Tunnel. Pivot In The Open - Double run to de-risk - MVP had to scale from day one - Start with thin slices + real clients Rebuild incrementally. In production. With feedback Brand new modular lambdalith External Systems Payment (Stripe) Seating (Seats.io) Shopping (Shopify) Messaging (Brevo)… Event Studio UI Event Shop UI API GTW Ticketing Marketplace UI Organizers Fans
100. Start with familiar concepts and incrementally introduce patterns REST API Distribution DB External Systems Offering Inventory Pricing Fulfillment Checkout Bounded Contexts
101. Start with familiar concepts and incrementally introduce patterns REST API DB External Systems Event Command Read Model Projection
102. Start with familiar concepts and incrementally introduce patterns REST API DB External Systems Event Command Read Model Projections Public Event
103. Start with familiar concepts and incrementally introduce patterns REST API DB External Systems Event Command Event Event Event PROJECTOR Read Model Query Public Event PROJECTOR
104. Where Do We Stand Today?
105. Where we stand today From this,
106. Where we stand today To this: a manageable infrastructure aligned with optimal team dynamics
107. Where we stand today 8 months later… ➔ Team changes: 2 team members left, and 3 new members joined over the past 6 months
108. Where we stand today 8 months later… ➔ Team changes: 2 team members left, and 3 new members joined over the past 6 months ➔ Achieved 1,200 RPS with minimal optimization efforts
109. Where we stand today 8 months later… ➔ Team changes: 2 team members left, and 3 new members joined over the past 6 months ➔ Achieved 1,200 RPS with minimal optimization efforts ➔ Created an auditable event store
110. Where we stand today 8 months later… ➔ Team changes: 2 team members left, and 3 new members joined over the past 6 months ➔ Achieved 1,200 RPS with minimal optimization efforts ➔ Created an auditable event store ➔ First successful event sales achieved after 6 months ➔ Organized 15 events since January
111. Where we stand today 8 months later… ➔ Team changes: 2 team members left, and 3 new members joined over the past 6 months ➔ Achieved 1,200 RPS with minimal optimization efforts ➔ Created an auditable event store ➔ First successful event sales achieved after 6 months ➔ Organized 15 events since January ➔ Deployment frequency of 20 times per month with a lead time of just 6 hours!
112. Conclusion
113. Looking back on what we've done
114. Looking back on what we've done • Shortcuts were necessary – We did what we could with what we had
115. Looking back on what we've done • Shortcuts were necessary – We did what we could with what we had • Breakthrough moment – Recognizing when it’s time to shift gears
116. Looking back on what we've done • Shortcuts were necessary – We did what we could with what we had • Breakthrough moment – Recognizing when it’s time to shift gears • Modern stack ≠ silver bullet – Basic capabilities to counter unfamiliarity
117. Looking back on what we've done • Shortcuts were necessary – We did what we could with what we had • Breakthrough moment – Recognizing when it’s time to shift gears • Modern stack ≠ silver bullet – Basic capabilities to counter unfamiliarity • Simple architecture wins – Even with complex domains
118. Looking back on what we've done • Shortcuts were necessary – We did what we could with what we had • Breakthrough moment – Recognizing when it’s time to shift gears • Modern stack ≠ silver bullet – Basic capabilities to counter unfamiliarity • Simple architecture wins – Even with complex domains • No feature is free – And sometimes, unshipping is the smart move
119. Looking back on what we've done • Shortcuts were necessary – We did what we could with what we had • Breakthrough moment – Recognizing when it’s time to shift gears • Modern stack ≠ silver bullet – Basic capabilities to counter unfamiliarity • Simple architecture wins – Even with complex domains • No feature is free – And sometimes, unshipping is the smart move • Alignment > tools – Tech helps, but team dynamics drive success
120. Thank you!