Join Newsletter

Monolith to Micro-Services? Event Sourcing Can Help

YOW! CTO Summit 2017 Melbourne

As Culture Amp's product group grew (now 70 people) it became increasingly obvious that having a single monolith and single codebase was slowing us down, and creating single points of failure. This talk will cover how we embraced event sourcing as an architectural pattern to help us refactor the monolith - helping us to identify the boundaries of context - in preparation for identifying and harvesting appropriately scoped micro-services.

The rigid conventions of how aggregates can communicate forces you to think deeply about what your Aggregates are, what Commands they should accept and what Events they should emit. Enforcing that Aggregates cannot access the internal data of any other aggregates (of the same type or otherwise) forces you to think in terms of high cohesion / low coupling, and, when necessary, accessing projections - and by inference accessing an external representation of another context.

The standard architectural patterns for CQRS and event sourcing introduce an eventual consistency problem that needs to be understood and designed for - particularly in the UI. However, if you're migrating a monolith much of your UI was likely build assuming the page loads only occur after the database and views are updated. One of the advantages of starting event sourcing just within your monolith is that you can force the projections to be updated before returning success to a command. This has obvious down sides - namely impacting performance, stability, separation of concerns, and scalability, however as a stepping stone towards introducing event sourcing it's a fantastic way to allow you to focus on the Command side of CQRS initially without having to make any UI changes.

Douglas English

Founder and VP of Engineering

Culture Amp

Australia

I spent the first decade of my professional career climbing the corporate ladder in consulting companies and large financial institutions. At a certain point I found myself in the unenviable position of not enjoying my job, but for the first time in my career having the foresight to realise I would enjoy my boss's job even less! Pub drinking sessions with a friend moved from complaining to imagining what ifs, and before we knew it we'd both agreed to quit and try our hand at building a startup. 2 companies and 3 failed products later I've found myself now riding the fast growth tech company journey we first imagined, and loving (almost!) every minute of it. Along the way I've met and collaborated with some amazingly smart and passionate people, learned a whole heap of new languages, approaches and business domains, and broadened my knowledge far beyond technology into the realms of marketing, sales, finance, and business development.