Roadmaps · L3
Senior Backend Developer
A senior backend developer owns not just their task but its effect on the system. They solve complex and ambiguous problems, make decisions on reliability and changeability, and help other engineers grow.
How it differs from the previous level
A middle developer does well inside one service. A senior accounts for interaction between services, failure scenarios and long-term consequences. They do not just solve problems; they choose which problems are worth solving and influence the quality of other people's work.
Expected knowledge
- The failure model of distributed systems: timeouts, retries, backoff, circuit breakers, bulkheads
- Messaging semantics: at-least-once delivery, idempotent consumers, transactional outbox
- Database depth: isolation levels, locking, migration strategies
- Idempotency and safe handling of repeated requests
- The JVM: memory model, GC choice, container limits, strengths and limits of virtual threads
- Observability: logs, metrics, traces and symptom-based alert design
- Service boundaries, data ownership, and choosing between a modular monolith and microservices
- API security: object-level authorization, rate limiting, secrets management
Practical skills
- Turn a vague requirement into a system design and state the trade-offs openly
- Predict and verify system behaviour under load and failure
- Narrow down the cause during an incident, then write a blameless postmortem
- Run a risky migration in stages with a rollback plan
- Give reasoned feedback in code and design reviews
- Mentor junior and middle engineers with concrete feedback
Common mistakes
- Solving every problem with a microservice and ending up with a distributed monolith
- Treating a database write and a message publish as one atomic step (dual write)
- Adding retries without backoff and jitter, which amplifies the outage
- Alerting on every small metric instead of on symptoms
- Making every decision personally and not letting the team become independent
- Choosing the technology before the problem
Learning priorities
- 1Make reliability part of the designThink about timeouts, retry policy and failure behaviour for every external call from the start.
- 2Know distributed data and messaging in depthOutbox, idempotent consumers, ordering and the effect of eventual consistency on user experience.
- 3Think systematically about system designClarify requirements, estimate roughly, state trade-offs and failure modes openly.
- 4Observability and operational cultureSymptom-based alerts, runbooks and postmortems. You must be able to understand the system at 3 a.m.
- 5Mentoring and influenceRaise the level of the team through reviews, design discussions and sharing knowledge.
Architecture maturity
At senior level, architectural decisions are judged by boundaries, data ownership and quality attributes such as reliability, performance, security and changeability. The engineer compares alternatives, states the cost of each decision and plans a way back. They apply principles such as clean architecture or DDD where they solve a concrete problem, not as ceremony.
Example questions
- How would you keep a database write and a Kafka message consistent?
- How does a retry storm start and how do you prevent it?
- What happens when a consumer receives the same message twice, and how do you prepare for it?
- How do you protect the rest of the system when a third-party API slows down?
- When would you justify microservices over a modular monolith?
- Where would you begin if GC pauses have increased?
- Design a URL shortener and explain the trade-offs.
Exercises you can do on your own
- Publish an 'order created' event with a transactional outbox and relay; kill the relay and verify reprocessing.
- Add a circuit breaker and a bulkhead against an external service, simulate failure and measure the behaviour.
- Add an idempotency key to a payment endpoint and test identical concurrent requests.
- Write an ADR for extracting one module of an existing monolith along its boundaries.
- From a real service's metrics and logs, define three symptom-based alerts and a runbook.
Articles for this level
- Distributed systemsFailure handling in distributed systems
- Event-driven architectureDelivery semantics, idempotent consumers and the outbox pattern
- Transactions and consistencyTransaction isolation levels and lost updates in PostgreSQL
- Distributed systemsIdempotency patterns for safe retries
- ObservabilityObservability: logs, metrics and traces
- System designSystem design walkthrough: a URL shortener
- Advanced JavaJava memory and garbage collection for service developers
- MicroservicesDrawing microservice boundaries
Programs that fit
How close are you to this level?
The skills assessment builds a personal gap report from your answers. It is a recommendation, not a certificate.