How a Tech Lead approaches architecture and system design
Architecture is not a diagram. It is a set of reversible and irreversible decisions that keep a system useful, reliable, secure, and operable as it changes.
Responsibilities
What the Tech Lead needs to own.
Start with users, workloads, constraints, failure modes, compliance needs, and measurable service objectives.
Define service boundaries, contracts, data ownership, consistency models, and migration paths.
Review security, observability, cost, scalability, operability, and rollback strategy before launch.
Record decisions and revisit them when scale, risk, or product assumptions change.
Strong signals
What good looks like.
Chooses the simplest design that satisfies current constraints and preserves future options.
Makes failure behavior and operational ownership explicit.
Validates assumptions with prototypes, load tests, production data, and staged delivery.
Evidence from Sanjay's work
Principles backed by delivery.
Designed asynchronous fast and slow lanes for reports ranging from seconds to hours.
Scaled reporting to 1M+ daily requests with retries, DLQs, idempotency, dashboards, and alerting.
Reduced data-extraction time by 60% and heap usage by 40% during performance work.
