Middle → Senior Engineering
A 16-week instructor-led program for middle developers: Java concurrency, caching, messaging with Kafka, resilience, data consistency, API design, performance profiling, observability, security in depth, design docs/ADRs and reviewing others' code. It ends with a service that you design, implement and defend, with a written design doc. This is a planned syllabus that may be adjusted to the group; there is no job guarantee.
This program is planned and not scheduled yet. No date, cohort or admission has been announced, and we are not accepting applications. Register interest or ask for a consultation and we will contact you when it is scheduled.
- Duration
- 16 weeks
- Live sessions
- 2 per week, 90 minutes each
- Structure
- 4 phases
16 weeks
Week-by-week syllabus
This is the planned syllabus: order and depth may be adjusted to the group. It is not a job or title guarantee.
01 · Weeks 1–4
Concurrency, caching and performance
Phase goal: Understand the Java concurrency model, locks versus optimistic approaches, virtual threads and caching; solve performance problems by measuring and profiling.
Week 1
Java concurrency: threads, the memory model, executors, virtual threads
- Race conditions, visibility and happens-before (Java Memory Model)
- synchronized, volatile and the atomic classes
- ExecutorService, thread-pool sizing and CompletableFuture
- Virtual threads (Java 21): when they help and when they do not
- Pinning, blocking I/O and enabling virtual threads in Spring Boot
Lab: Create a race condition on a shared counter with a stress test and fix it with synchronized, atomics and a lock; compare platform and virtual threads on 10,000 blocking tasks.
Assignment: Money transfer between accounts: a test that reproduces the race, three fix approaches (global lock, ordered per-account locks, CAS) and a measurement report; Pull Request.
Week 2
Locks, deadlocks and optimistic concurrency
- ReentrantLock, ReadWriteLock, StampedLock and lock ordering
- Deadlock, livelock, starvation: diagnosis (thread dumps)
- Optimistic vs pessimistic locking: JPA @Version and SELECT FOR UPDATE
- Lost updates, write skew and lock-free approaches (CAS)
- Concurrent collections and thread-safe design: immutability
Lab: Analyse a deliberately deadlocking program with a thread dump and fix it; create a lost update on an inventory with concurrent requests and solve it with @Version.
Assignment: Solve overselling in a reservation service both optimistically and pessimistically and write a short ADR comparing them by throughput and retry count; Pull Request.
Week 3
Caching: strategies, invalidation, stampede
- Cache-aside, read-through, write-through, write-behind
- Caffeine (in-process) vs Redis (distributed): trade-offs
- TTL, invalidation and living with stale data
- Cache stampede, request coalescing and negative caching
- The Spring Cache abstraction and measuring hit rate
Lab: Put an expensive query behind a Caffeine cache, simulate a stampede, then fix it with a single-flight approach and measure hit rate and latency.
Assignment: Add a cache to a product-catalog endpoint: TTL and invalidation decisions, a hit-rate metric and a stampede test; record the decision as an ADR; Pull Request.
Week 4
Performance profiling and load testing
- A measurement culture: latency percentiles (p50/p95/p99), throughput, saturation
- JFR and async-profiler: CPU, allocation, lock profiles
- GC basics, heap dumps and finding a memory leak
- Micro-benchmarks with JMH and their traps
- Load testing with k6/Gatling and hunting bottlenecks
Lab: Profile a slow service with JFR, find and fix the biggest bottleneck, and compare p95 latency before/after with k6.
Assignment: A performance report for the provided service: hypothesis, measurement method, profile result, fix, before/after numbers; Pull Request with the code fix.
Checkpoint: A stress test reproducing a concurrency bug, a cache-strategy decision and a profiler-backed performance fix (before/after measurements).
02 · Weeks 5–8
Messaging and data consistency
Phase goal: Apply Kafka basics, the outbox and idempotency patterns, sagas and isolation levels in practice, and understand the 'exactly-once' myth.
Week 5
Kafka fundamentals: topics, partitions, consumer groups
- The log model: topics, partitions, offsets and ordering guarantees
- Producers: acks, retries, batching, partitioning by key
- Consumer groups, rebalancing and offset commit strategies
- At-most-once / at-least-once delivery
- Spring Kafka and testing Kafka with Testcontainers
Lab: Build an order-event flow on local Kafka; deliberately crash the consumer to observe redelivery and show that per-key order is preserved.
Assignment: An Order service publishes events and a Notification service consumes them; a Testcontainers test proving at-least-once behaviour; Pull Request.
Week 6
Outbox, idempotency and the 'exactly-once' myths
- The dual-write problem: DB and broker drifting apart
- Transactional outbox and relay (polling / CDC)
- Idempotent consumers: inbox tables and dedup keys
- Kafka idempotent producer and transactions: what they guarantee and what they do not
- Poison messages, retry topics and DLQs
Lab: Reproduce a dual-write bug (the DB write succeeds, the event is lost), fix it with an outbox, and show the consumer is idempotent by sending the same message twice.
Assignment: Add an outbox to Order and inbox/dedup to Notification; failure tests (relay crashes, duplicate message); a short explanation of 'exactly-once'; Pull Request.
Week 7
Distributed transactions and sagas
- Why 2PC is hard in practice, and the alternatives
- Sagas: orchestration vs choreography
- Compensating actions and half-finished states
- Saga state, timeouts and idempotent steps
- Observability: seeing where a saga is stuck
Lab: Build an orchestrated saga for an order → payment → inventory flow and demonstrate compensation when payment fails.
Assignment: A saga/consistency decision note for the capstone: which operations need a saga and which stay local transactions; implement and test one saga; Pull Request.
Week 8
Data consistency: isolation, read models and eventual consistency
- PostgreSQL isolation levels and anomalies (non-repeatable read, write skew)
- Serializable with retries; advisory locks
- CQRS-lite: read models and projections
- UX with eventual consistency: read-your-writes
- Detecting drift and reconciliation jobs
Lab: Reproduce a write-skew anomaly with two parallel transactions and prevent it with SERIALIZABLE or a constraint.
Assignment: Build a read model (projection) from order events, test rebuilding it and a reconciliation job; Pull Request.
Checkpoint: A two-service flow with an outbox and an idempotent consumer, tests for failure scenarios and a saga decision note.
03 · Weeks 9–12
Resilience, API design and observability
Phase goal: Make a service resilient to dependency failures, evolve an API through versioning, and measure the system with metrics, tracing and SLOs.
Week 9
Resilience: timeouts, retries, circuit breakers
- Timeouts on every call: connect, read and overall deadline
- Retries: exponential backoff, jitter and retry budgets
- Circuit breakers: states and tuning (Resilience4j)
- Bulkheads and isolating dependencies
- The false safety of fallbacks and degraded modes
Lab: Simulate a slow dependency (WireMock delay), observe a retry storm, then stabilise with timeout + backoff + circuit breaker.
Assignment: Make the payment-provider call resilient: timeouts, retry budget, circuit breaker, idempotency key; failure tests; Pull Request.
Week 10
Backpressure, rate limiting and load shedding
- Queues and Little's law: why latency explodes
- Bounded queues, backpressure and consumer lag in Kafka
- Rate-limiting algorithms: token bucket, sliding window
- Load shedding and prioritisation
- The limits of autoscaling and capacity planning
Lab: Drive a service with an unbounded queue to memory exhaustion under load, then fix it with a bounded queue and 429 responses.
Assignment: Add a token-bucket rate limiter and load shedding to the service; a k6 test showing accepted vs rejected requests; Pull Request.
Week 11
API design, versioning and contracts
- Resource modelling, idempotent methods and Idempotency-Key
- Pagination, filtering, ETags and conditional requests
- The error model: RFC 9457 problem details
- Versioning: URL, header, additive evolution and deprecation
- Contract testing (Spring Cloud Contract / Pact) and OpenAPI
Lab: Make a breaking change to an API and break a client, then make the same change safely through additive evolution and a contract test.
Assignment: The capstone API's OpenAPI document, versioning/deprecation policy and a consumer contract test; Pull Request.
Week 12
Observability: metrics, tracing and SLOs
- Three pillars: logs, metrics, traces and how they connect
- RED/USE methods and good metric design (cardinality)
- Distributed tracing with OpenTelemetry
- SLIs, SLOs, error budgets and alerting that makes sense
- Dashboards and runbooks for on-call
Lab: Wire an OpenTelemetry trace across two services and find a slow call from the trace; write an SLO-based burn-rate alert.
Assignment: SLI/SLO definitions, a dashboard JSON, alert rules and a runbook for the capstone service; Pull Request.
Checkpoint: A service that stays within its SLO in a chaos scenario (slow/failed dependency), an API versioning decision and a dashboard + alert definition.
04 · Weeks 13–16
Security, design decisions, mentoring and capstone
Phase goal: Apply security in depth, justify trade-offs in writing with design docs/ADRs, review and mentor others, and defend a capstone service.
Week 13
Security in depth: threat modeling and defense in depth
- Threat modeling: STRIDE and trust boundaries
- OAuth2/OIDC, JWT pitfalls and token rotation
- Resource-level authorization and multi-tenancy leaks
- Secret management, supply chain and dependency scanning
- Audit logs, rate limiting and designing against abuse
Lab: Run a 45-minute STRIDE threat-modeling session for the provided service, pick the 5 riskiest threats and write an exploit test for one.
Assignment: A threat-model document for the capstone and implementation of at least 3 security controls with authorization tests; Pull Request.
Week 14
Design docs, ADRs and trade-off analysis
- Design-doc structure: context, goals/non-goals, alternatives
- Writing ADRs: decision, rationale, consequences
- Trade-off analysis: decision matrices and reversibility
- Estimation: capacity calculations and back-of-envelope maths
- Design reviews: asking questions and defending answers
Lab: Review a provided design doc in 15 minutes, write the 5 key questions and 2 risks, then hear the author's answers in a defense session.
Assignment: Write the capstone service's design doc (2–4 pages) and at least 3 ADRs; submit for peer review (Pull Request).
Week 15
Reviewing others' code, mentoring and capstone implementation
- Senior-level review: design, risk, test gaps
- The language of feedback: question vs instruction, blocking vs nit
- Mentoring juniors: pair programming and delegating tasks
- Technical debt: sizing it and negotiating it
- Capstone implementation: vertical slices and feature flags
Lab: Review a junior colleague's Pull Request (separating blocking from nit comments) and run a 30-minute pair-programming session.
Assignment: The core of the capstone implementation (including tests, observability, security) and written reviews of 2 peers' Pull Requests; Pull Request.
Week 16
Capstone defense
- Final trials for the service: chaos, load, security
- Updating the design doc: what changed and why
- A 20-minute defense: demo, trade-offs, measurements
- Q&A: defending the design against the panel's questions
- Retrospective and a growth plan towards senior level
Lab: Run the final chaos and load tests and add the results to the design doc; a dry-run of the defense.
Assignment: The final repository (code, tests, design doc, ADRs, runbook), a 20-minute defense and a self-assessment note.
Checkpoint: A design doc, an implemented service (tests, observability, security), at least 3 ADRs and a 20-minute defense.