Solution Architecture: Choosing Which Patterns to Ignore

Most organisations I speak with still look for a “best practice” playbook when it comes to architecture.

There isn’t one.

Every architecture choice is a compromise: performance or flexibility, simplicity or scale, speed now or resilience later. Books and frameworks can help you see the patterns, but they rarely tell you which pain is worth enduring for your business.

Microservices sound like progress. Until you’re tangled in operational overhead and fragmented data. Monoliths seem outdated. Until you need reliable change control and don’t have a dev army.

And Domain-Driven Design? Useful, but only if your teams actually understand your business domains otherwise, you just end up with new silos, not better alignment.

What’s missing from most advice is context. Size of team. Appetite for risk. Regulatory exposure. None of this fits on a checklist.

The smartest banks I know use books as guardrails, not gospel. They learn the trade-offs, then obsess over how those trade-offs play out in their unique environment.

Architecture isn’t about chasing trends or collecting certifications. It’s about understanding which constraints matter most to you and building your stack to match.

The hard part isn’t knowing the patterns. It’s knowing which ones to ignore.