4 talented speakers, 3 scaling tech business, 2 hours+ of networking down the pub and 1 brilliant office space to host = another successful tech meetup. ✅
Thanks to everyone who joined us at our latest tech meetup, ‘Building Software That Scales’. Organised by our London Software Engineering team, we bought together an all-female line-up of Software Engineers who each tackled an aspect of the topic.
When speaking with our network to find out about the challenges they were facing in their teams, and to uncover the topics that people were most interested in hearing about, scaling quickly became the number one theme.
Our host for the evening was AI unicorn, Tractable. Since kick-starting their mission to accelerate accident and disaster recovery in 2014, Tractable’s product reach has increased three-fold, so they know a thing or two about scaling quickly…
Representing Tractable were Full Stack Engineers Georgina & Wei Ann, who were joined by Kate from Cervest and Sarah from Gousto to complete our speaker panel.
We’ve shared a round up of all the talks along with the recordings from the night, so check out all the highlights below.
🎙 Know Before You Grow: Engineering Products That Scale
Georgina Steele & Wei Ann Heng, Full Stack Engineers @ Tractable
In order to overcome growth bottlenecks during their rapid period of growth, Tractable’s engineering teams adopted a product focus to scale rapidly. Here are some of the key lessons they learnt from the process:
Lesson 1: Simpler solutions allow for greater scalability.
Previously, Tractable’s customer journeys were rigid and complicated. Customers were difficult to onboard due to a lack of flexibility in the flow and processes often required unnecessary manual intervention. Instead, by removing customer logic and separating the responsibility of orchestration, workflows became much more flexible and enabled the team to grow their customer base at a much faster pace.
Lesson 2: Customer needs vs. product needs
As you scale your customer base, you need to separate product needs from customer needs within your code. Tractable did this by separating out client configuration from product teams to increase responsiveness. This allowed customer teams to manage customer configuration and product engineers to focus on developing the product.
Lesson 3: Domain-driven teams led to increased efficiency
As companies and products scale quickly, teams often need to be re-shaped to optimise collaboration and efficiency. When teams become stretched to cover excessive responsibilities, they often end up switching between different contexts and having no real ownership of a domain. As Tractable grew and looked to optimise the structure of their teams, they wanted to obey two constraints: team cognitive load & Conway’s law.
Cognitive load: “The total amount of mental effort being used in the working memory.” -John Sweller, 1988
Conway’s Law: “Any organisation that designs a system (…) will produce a design whose structure is a copy of the organisation’s communication structure.” - Melvin Conway, 1968
By organising teams by domains, communication between teams mimicked the communication between services and led to faster engineers with less cognitive load.
🎙 How To Find Appropriate Technologies For The Load & Wallet
Kate Yanchenko, Senior Data Engineer @ Cervest
With over 8 years of experience in Software Engineering, Kate has a passion for designing and developing large scale applications, cloud computing and distributed systems. And with a recession looming, Kate’s talk tackled a very relevant challenge for many right now; how to find suitable technologies for the load whilst keeping costs low.
Kate walked us through the process of getting the cost of a TTL (Time to live service) from $480,000 a month using Kafka, down to $21,200 by reusing the design patterns from Kafka, and rebuilding in database stream + S3. She also highlighted the hidden costs of the chosen technologies, which helped to see if this technology was cost-effective for our scenario.
🎙 Supercharge Your Scaling With Event-Driven Architecture
Sarah Anderson, Tech Lead @ Gousto
Having helped several start-ups solve the problem of how to scale-up a monolith using modern infrastructure practices, Sarah took us through the process of using event-driven architecture to scale, and the different approaches to implementation, including:
- Event Notification
- Event Carried State Transfer
- Event Sourcing Patterns
So, what are the pro’s of event-driven architecture?
Scaling for usage:
✂️ Event Driven Architecture leads to having decoupled services.
🔗 Decoupled services can be scaled more effectively as usage is split across different services.
🔄 Asynchronous communication layer reduces services usage affecting one another.
Scaling for Engineering size:
🤝 Following Event Driven Design Principles, service boundaries become easier to establish and maintain.
👨👨👦 Ownership of services can be defined per team.
💬 A common communication pattern with defined schemas reduces blockers on other teams.
A huge thank you to our 4 excellent speakers for presenting – you can connect with them all via the links below. If you'd like to give event speaking a go yourself, you can register your interest here and let us know what topics you're interested in sharing with the tech community. We're always keen to hear what you want to see and hear at these events, so please share any thoughts with us so that we keep organising events you actually want to attend!
Our next events taking place in September will be…
📆 Thursday 15th September: Data Analytics Tech Meetup featuring speakers from Dojo, DAZN, Bumble & Lightdash.
📆 Thursday 22nd September: Product Panel event featuring speakers from Tide, Monzo, Dojo & Liberis - 'Scale Fast or Fail Slow'
Stay tuned, we'll be sharing more details very soon...