Making good architecture decisions — Re: Segment

Matt James
Sep 3, 2018 · 2 min read

There’s been a lot of the times where I’ve used a design pattern or architecture where it felt like I was swimming upstream. I often blamed my inability to implement it properly — only later I realised I was jamming a square peg in a round hole.

In the past I’ve taken taken some odd routes, I’ve:
* removed versioning
* deleted shared packages
* copy-pasted shared package code into different repos
* mashed services and repos together
* deleted a bunch of tests
And although no hipster dev blog would advocate these — they were all the right things to do at the time in that specific scenario. Every good design choice is also a good compromise.

I’ve seen a lot of developers with cognitive dissonance on seeing the downsides to certain things — often because there’s so much momentum in the industry that it just feels right. Or it seems so cool you want it to be right.

Every architecture choice you make has down sides, if a certain decision looks like a slam dunk to you — take a strategic pause. The way to make good design decisions is to be able to articulate (in great detail) the problems you are introducing with your design — and how the benefits are worth putting up with these problems. It is often very painful to criticise something that you really hope will fix all your issues. Critical thinking is key to accomplishing this.

Segment has had an awesome journey from monolith to microservices+queuing, back to monolith, before landing on the architecture that suited their problem the best — their “centrifuge”. Throughout the journey they learnt that they needed to find an architecture that suited their specific problem, not the other way round. “Don’t outsource your thinking”.

Post — https://segment.com/blog/goodbye-microservices/
Podcast — https://itunes.apple.com/au/podcast/the-changelog/id341623264?mt=2&i=1000418716109

* I would say though that applying a little DDD would’ve gone a long way to realise their 140 services weren’t aligned to any domain boundaries. Their centrifuge ended up looking very much like aggregates in an event store.
* it’s more important to understand the cons than the pros of a new design
* measurements are critical to validating your design decisions