Architecture
Event-driven by default? When (and when not) to reach for it
Event-driven architecture is powerful - and over-applied. A practical lens for picking the right pattern for the right problem.
Read article →The patterns in this article come from our work with large enterprises across regulated and fast-moving sectors. The aim is not to be exhaustive - it is to surface the handful of decisions we see making the biggest difference in practice.
1. The leverage equation
A small team with a great platform will out-deliver a large team without one - every time. Leverage comes from automation, abstraction and a relentless focus on removing toil from the path to production.
2. Trunk-based delivery, by default
Long-lived branches are an organisational smell. They mean integration is being deferred, which means risk is accumulating somewhere out of sight. Trunk-based development with feature flags surfaces integration problems early, where they are cheap to fix.
3. Observability before scale
It is far cheaper to add observability before you need it than during an incident. Logs, metrics and traces should be a non-negotiable part of every service template - not a retrofit project after the first outage.
4. Platforms, not frameworks
Internal platforms succeed when they are treated as products with users, not frameworks imposed on teams. The platform team’s job is to make the right thing the easy thing.
Where to start
If any of the above resonates with what you are working through, we are always happy to compare notes - without obligation. Email is the best way to reach us: customerservices@halfteck.com.