Middle → Senior Engineering
Middle developer-lər üçün 16 həftəlik instructor-led proqram: Java-da concurrency, caching, Kafka ilə mesajlaşma, resilience, data consistency, API dizaynı, performance profiling, observability, dərin təhlükəsizlik, design doc/ADR və başqalarının kodunu review etmək. Proqram dizayn edilmiş, implementasiya olunmuş və müdafiə edilmiş servis və yazılı design doc ilə bitir. Plan edilmiş sillabusdur, qrupa görə tənzimlənə bilər; iş təminatı vədi yoxdur.
Bu proqram planlaşdırılır və hələ cədvələ salınmayıb. Tarix, qrup və qəbul açıq elan olunmayıb; müraciət qəbul etmirik. Maraq bildirin və ya konsultasiya istəyin: proqram planlaşdırıldıqda sizinlə əlaqə saxlayarıq.
- Müddət
- 16 həftə
- Canlı dərslər
- həftədə 2 dərs, hər biri 90 dəqiqə
- Mərhələ
- 4 mərhələ
16 həftə
Həftə-həftə tədris planı
Planlaşdırılan tədris planıdır: sıra və dərinlik qrupa uyğun dəyişə bilər. İş təminatı və ya vəzifə vədi deyil.
01 · 1–4-cü həftələr
Concurrency, caching və performans
Mərhələnin məqsədi: Java-da concurrency modelini, lock və optimistic yanaşmaları, virtual thread-ləri və caching-i anlamaq; performans problemlərini ölçüb profil edərək həll etmək.
Həftə 1
Java concurrency: thread-lər, memory model, executor-lar, virtual thread-lər
- Race condition, visibility və happens-before (Java Memory Model)
- synchronized, volatile və atomic sinifləri
- ExecutorService, thread pool ölçüsü və CompletableFuture
- Virtual thread-lər (Java 21): nə vaxt kömək edir, nə vaxt yox
- Pinning, blocking I/O və Spring Boot-da virtual thread aktivləşdirmək
Laboratoriya: Paylaşılan sayğacda race condition-ı stress testlə yaradıb synchronized, atomic və lock ilə düzəltmək; platform və virtual thread-ləri 10 000 bloklayan tapşırıqda müqayisə etmək.
Tapşırıq: Hesablararası pul köçürməsi: race-i təkrarlayan test, üç düzəliş yanaşması (global lock, sıralı per-account lock, CAS) və ölçmə hesabatı; Pull Request.
Həftə 2
Lock-lar, deadlock və optimistic concurrency
- ReentrantLock, ReadWriteLock, StampedLock və lock ordering
- Deadlock, livelock, starvation: diaqnoz (thread dump)
- Optimistic vs pessimistic locking: JPA @Version və SELECT FOR UPDATE
- Lost update, write skew və lock-suz yanaşmalar (CAS)
- Concurrent koleksiyalar və thread-safe dizayn: immutability
Laboratoriya: Qəsdən deadlock olan proqramı thread dump ilə analiz edib düzəltmək; inventar yeniləməsində eyni vaxtlı sorğularla lost update yaradıb @Version ilə həll etmək.
Tapşırıq: Rezervasiya servisində oversell-i optimistic və pessimistic yolla həll etmək, iki yanaşmanı throughput və retry sayı ilə müqayisə edən qısa ADR yazmaq; Pull Request.
Həftə 3
Caching: strategiyalar, invalidation, stampede
- Cache-aside, read-through, write-through, write-behind
- Caffeine (in-process) vs Redis (distributed): trade-off-lar
- TTL, invalidation və 'cache-də stale data' ilə yaşamaq
- Cache stampede, request coalescing və negative caching
- Spring Cache abstraksiyası və hit-rate ölçülməsi
Laboratoriya: Bahalı sorğunu Caffeine cache-ə qoyub stampede-i simulyasiya etmək, sonra single-flight yanaşması ilə həll edib hit-rate və gecikməni ölçmək.
Tapşırıq: Məhsul kataloqu endpoint-inə cache əlavə etmək: TTL və invalidation qərarı, hit-rate metriki və stampede testi; qərarı ADR kimi yazmaq; Pull Request.
Həftə 4
Performance profiling və load test
- Ölçmə mədəniyyəti: latency percentiles (p50/p95/p99), throughput, saturation
- JFR və async-profiler: CPU, allocation, lock profil
- GC əsasları, heap dump və yaddaş sızıntısının tapılması
- JMH ilə mikro-benchmark və onun tələləri
- k6/Gatling ilə load test və bottleneck axtarışı
Laboratoriya: Yavaş servisi JFR ilə profil edib ən böyük bottleneck-i tapmaq və düzəltmək; k6 ilə əvvəl/sonra p95 gecikməni müqayisə etmək.
Tapşırıq: Verilmiş servis üçün performance hesabatı: hipotez, ölçmə metodu, profil nəticəsi, düzəliş, əvvəl/sonra rəqəmlər; kod düzəlişi ilə Pull Request.
Yoxlama nöqtəsi: Concurrency bug-ı təkrarlayan stress test, cache strategiyası qərarı və profiler ilə sübut olunmuş performans düzəlişi (əvvəl/sonra ölçmə).
02 · 5–8-cü həftələr
Mesajlaşma və data consistency
Mərhələnin məqsədi: Kafka əsaslarını, outbox və idempotency pattern-lərini, saga və isolation səviyyələrini praktikada tətbiq edib 'exactly-once' mifini anlamaq.
Həftə 5
Kafka əsasları: topic, partition, consumer group
- Log modeli: topic, partition, offset və sıralama zəmanəti
- Producer: acks, retries, batching, key-ə görə partition
- Consumer group, rebalance və offset commit strategiyaları
- At-most-once / at-least-once çatdırılma
- Spring Kafka və Testcontainers ilə Kafka testi
Laboratoriya: Lokal Kafka-da sifariş hadisələri axını qurmaq; consumer-i qəsdən çökdürüb təkrar çatdırılmanı müşahidə etmək və key-ə görə sıranın qorunduğunu göstərmək.
Tapşırıq: Order servisi hadisə yayır, Notification servisi istehlak edir; at-least-once davranışını sübut edən Testcontainers testi; Pull Request.
Həftə 6
Outbox, idempotency və 'exactly-once' mifləri
- Dual-write problemi: DB və broker arasında uyğunsuzluq
- Transactional outbox və relay (polling / CDC)
- Idempotent consumer: inbox cədvəli və dedup açarı
- Kafka idempotent producer və transactions: nəyi zəmanət edir, nəyi etmir
- Poison message, retry topic və DLQ
Laboratoriya: Dual-write bug-ını (DB-yə yazılır, hadisə itir) təkrarlayıb outbox ilə həll etmək; eyni mesajı iki dəfə göndərərək consumer-in idempotent olduğunu göstərmək.
Tapşırıq: Order servisinə outbox, Notification servisinə inbox/dedup əlavə etmək; nasazlıq testləri (relay çökür, mesaj dublikat gəlir); 'exactly-once' haqqında qısa izah; Pull Request.
Həftə 7
Paylanmış transaction-lar və saga
- Niyə 2PC çətin işləyir və alternativlər
- Saga: orchestration vs choreography
- Kompensasiya əməliyyatları və yarımçıq vəziyyətlər
- Saga state, timeout və idempotent addımlar
- Müşahidə: saga-nın hansı mərhələdə ilişdiyini görmək
Laboratoriya: Sifariş → ödəniş → inventar axını üçün orchestrated saga qurub ödəniş uğursuz olduqda kompensasiyanı göstərmək.
Tapşırıq: Capstone üçün saga/consistency qərar sənədi: hansı əməliyyatlar saga, hansılar lokal transaction olmalıdır; bir saga-nın implementasiyası və testi; Pull Request.
Həftə 8
Data consistency: isolation, read model və eventual consistency
- PostgreSQL isolation səviyyələri və anomaliyalar (non-repeatable read, write skew)
- Serializable və retry; advisory lock
- CQRS-lite: read model və proyeksiyalar
- Eventual consistency ilə UX: oxu-öz-yazını-gör (read-your-writes)
- Uyğunsuzluğun aşkarlanması və reconciliation işləri
Laboratoriya: Write skew anomaliyasını iki paralel transaction ilə təkrarlayıb SERIALIZABLE və ya constraint ilə qarşısını almaq.
Tapşırıq: Sifariş hadisələrindən read model (proyeksiya) qurmaq, onu yenidən qurmağı (rebuild) və reconciliation işini test etmək; Pull Request.
Yoxlama nöqtəsi: Outbox + idempotent consumer ilə işləyən iki servisli axın, nasazlıq ssenariləri üçün testlər və saga qərar sənədi.
03 · 9–12-cü həftələr
Resilience, API dizaynı və observability
Mərhələnin məqsədi: Servisi xarici asılılıqların nasazlığına davamlı etmək, API-ni versiyalamaqla təkamül etdirmək, metrik, tracing və SLO ilə sistemi ölçmək.
Həftə 9
Resilience: timeout, retry, circuit breaker
- Hər çağırışda timeout: connect, read və ümumi deadline
- Retry: exponential backoff, jitter və retry budget
- Circuit breaker: halları və tənzimləmə (Resilience4j)
- Bulkhead və asılılıqların izolyasiyası
- Fallback-lərin yalan təhlükəsizliyi və degraded rejim
Laboratoriya: Yavaş xarici asılılığı simulyasiya edib (WireMock delay) retry fırtınasını müşahidə etmək, sonra timeout + backoff + circuit breaker ilə sabitləşdirmək.
Tapşırıq: Ödəniş provayderi çağırışını davamlı etmək: timeout-lar, retry budget, circuit breaker, idempotency key; nasazlıq testləri; Pull Request.
Həftə 10
Backpressure, rate limiting və load shedding
- Queue-lar və Little qanunu: gecikmə niyə partlayır
- Bounded queue, backpressure və Kafka consumer-də lag
- Rate limiting alqoritmləri: token bucket, sliding window
- Load shedding və prioritetləşdirmə
- Autoscaling-in limitləri və capacity planlama
Laboratoriya: Limitsiz queue-lu servisi yük altında yaddaş tükənməsinə aparıb, bounded queue və 429 cavabı ilə düzəltmək.
Tapşırıq: Servisə token-bucket rate limiter və load shedding əlavə etmək; k6 ilə qəbul olunan və rədd edilən sorğuları göstərən test; Pull Request.
Həftə 11
API dizaynı, versiyalama və müqavilələr
- Resurs modelləşdirilməsi, idempotent metodlar və Idempotency-Key
- Pagination, filtering, ETag və şərti sorğular
- Xəta modeli: RFC 9457 problem details
- Versiyalama: URL, header, additive təkamül və deprecation
- Contract testing (Spring Cloud Contract / Pact) və OpenAPI
Laboratoriya: API-də breaking change edib müştərini sındırmaq, sonra additive təkamül və contract testi ilə eyni dəyişikliyi təhlükəsiz etmək.
Tapşırıq: Capstone API-sinin OpenAPI sənədi, versiyalama/deprecation siyasəti və consumer contract testi; Pull Request.
Həftə 12
Observability: metrik, tracing və SLO
- Üç sütun: log, metrik, trace və onların əlaqəsi
- RED/USE metodları və yaxşı metrik dizaynı (cardinality)
- OpenTelemetry ilə distributed tracing
- SLI, SLO, error budget və alert-in düzgün qurulması
- Dashboard-lar və on-call üçün runbook
Laboratoriya: İki servis arasında OpenTelemetry trace-i qurub yavaş çağırışı trace-dən tapmaq; SLO-ya əsaslanan burn-rate alert-i yazmaq.
Tapşırıq: Capstone servisi üçün SLI/SLO təyinatı, dashboard JSON-u, alert qaydaları və runbook; Pull Request.
Yoxlama nöqtəsi: Chaos ssenarisində (yavaş/düşmüş asılılıq) SLO daxilində qalan servis, API versiyalama qərarı və dashboard + alert təyinatı.
04 · 13–16-cü həftələr
Təhlükəsizlik, dizayn qərarları, mentorluq və capstone
Mərhələnin məqsədi: Təhlükəsizliyi dərin qatlarda tətbiq etmək, design doc/ADR ilə trade-off-ları yazılı əsaslandırmaq, başqalarının kodunu review edib mentorluq etmək və capstone servisi müdafiə etmək.
Həftə 13
Dərin təhlükəsizlik: threat modeling və defense in depth
- Threat modeling: STRIDE və trust boundary-lər
- OAuth2/OIDC, JWT tələləri, token rotation
- Resurs səviyyəli authz, multi-tenancy sızıntıları
- Secret idarəsi, supply-chain və asılılıq skanı
- Audit log, rate limiting və abuse hallarına qarşı dizayn
Laboratoriya: Verilmiş servis üçün 45 dəqiqəlik STRIDE threat modeling sessiyası keçirib 5 ən riskli təhdidi seçmək və biri üçün exploit testi yazmaq.
Tapşırıq: Capstone üçün threat model sənədi və ən azı 3 təhlükəsizlik nəzarətinin implementasiyası + authorization testləri; Pull Request.
Həftə 14
Design doc, ADR və trade-off analizi
- Design doc-un strukturu: kontekst, məqsəd/qeyri-məqsəd, alternativlər
- ADR yazmaq: qərar, səbəb, nəticə
- Trade-off analizi: qərar matrisi, geri dönməzlik dərəcəsi
- Qiymətləndirmə: capacity hesablamaları və 'back-of-envelope'
- Dizayn review-su: sual vermək və cavab müdafiə etmək
Laboratoriya: Verilmiş design doc-u 15 dəqiqə ərzində review edib əsas 5 sual və 2 risk yazmaq; sonra müəllifin cavablarını müdafiə seansında dinləmək.
Tapşırıq: Capstone servisinin design doc-unu (2–4 səhifə) və ən azı 3 ADR-i yazmaq; peer review üçün göndərmək (Pull Request).
Həftə 15
Başqalarının kodunu review etmək, mentorluq və capstone implementasiyası
- Senior səviyyəli review: dizayn, risk, test boşluqları
- Rəy dili: sual vs təlimat, blocking vs nit
- Junior-a mentorluq: pair programming və tapşırıq verilməsi
- Texniki borc: qiymətləndirmə və danışıq
- Capstone implementasiyası: vertikal dilimlər, feature flag
Laboratoriya: Junior həmkarın Pull Request-ini review etmək (blocking və nit rəyləri ayıraraq) və 30 dəqiqəlik pair-programming sessiyası keçirmək.
Tapşırıq: Capstone implementasiyasının əsas hissəsi (testlər, observability, təhlükəsizlik daxil) və 2 həmyaşıd Pull Request-ə yazılı review; Pull Request.
Həftə 16
Capstone müdafiəsi
- Servisin yekun sınaqları: chaos, load, təhlükəsizlik
- Design doc-un yenilənməsi: nə dəyişdi və niyə
- 20 dəqiqəlik müdafiə: demo, trade-off-lar, ölçmələr
- Sual-cavab: komissiyanın sualları ilə dizaynı müdafiə etmək
- Retrospektiv və senior səviyyəyə inkişaf planı
Laboratoriya: Yekun chaos və load testlərini keçirib nəticələri design doc-a əlavə etmək; müdafiəyə hazırlıq prosesi (dry run).
Tapşırıq: Yekun repozitoriya (kod, testlər, design doc, ADR-lər, runbook), 20 dəqiqəlik müdafiə və öz-qiymətləndirmə qeydi.
Yoxlama nöqtəsi: Design doc, implementasiya olunmuş servis (testlər, observability, təhlükəsizlik), ən azı 3 ADR və 20 dəqiqəlik müdafiə.