One way I've seen architectures get really complex really quickly, is when engineers try to foresee and plan to multiple rare non-critical scenarios.
The famous "what if" driven architecture:
- What if we get 10k concurrent users tomorrow? Everything needs to be CQRS event-driven, HA queue backed, produced and consumed by a fleet of microservices or it wont work perfectly!
- What if the user loses their internet connectivity while submitting this mundane form? We need localstorage backup for all CRUD operations and implement custom conflict resolution logic for each POST/PUT/DELETE.
I mean, yes we can try to tackle all possible issues and outcomes in our timeline but the sun would have cooled down by the time we are done.
Sometimes, well most of the times, you just gotta keep the project focused and 80/20 it.
Last year I did an interview and during the "systems design" phase I was asked to design a video streaming platform for 500 million simultaneous users. For a platform that has maybe a few thousand users, and is very unlikely to every get more than 10,000s users because it's just not general enough.
I never did find out if the test was to recognize that the number was off-the-walls crazy and that this would be the largest platform on earth by a substantial margin, or if they really thought that was a reasonable number. I suspect it's the latter :-/ I didn't get hired anyway, so...
I've also seen microservices for B2B software with low-hundreds of users. If the number of users is within an order of a magnitude of the number of services, then your developers are in need of adult supervision and a spanking.
Got into a similar argument the other day... The lead Architect wanted to create temporary ids so that a foreign system could pull a request only once, after they'd been notified so as to prevent "overload" of requesting every account every hour as a counter example... "so like 40k requests an hour?" BFD.
I had at least won that one... the id's will be date driven, natural keys per account and return a 404 if it doesn't exist yet. They'll still get a notification (web-hook) when the event for creation happens, but still far less complex then temporary id's that only work once, and require manual intervention if something breaks and needs to repeat.
I absolutely hate unnecessary complexity and tend to fight it at nearly every step.
If I didn't need the income, I'd be working on an email/calendar platform to replace Outlook+Exchange/O365. It's a space begging for disruption and not enough focus on some of the more critical needs that they provide that competitors tend to miss. Google comes the closest IMO.
100% I believe this is the most common pitfall that I've seen. Long-term thinking is an acquired skill when it comes to engineering good solutions. Unfortunately after (sometimes) years of over-engineering solutions in your career, the "a-ha" is that you definitely wasted your time and worse: often made iteration based on actual requirements slower by creating flexibility in one preconceived way, whilst adding rigidity in many others. KISS gets you real far
The famous "what if" driven architecture:
- What if we get 10k concurrent users tomorrow? Everything needs to be CQRS event-driven, HA queue backed, produced and consumed by a fleet of microservices or it wont work perfectly!
- What if the user loses their internet connectivity while submitting this mundane form? We need localstorage backup for all CRUD operations and implement custom conflict resolution logic for each POST/PUT/DELETE.
I mean, yes we can try to tackle all possible issues and outcomes in our timeline but the sun would have cooled down by the time we are done.
Sometimes, well most of the times, you just gotta keep the project focused and 80/20 it.