Kısım II · İnşaat · Bölüm 45

Uçtan Uca

Uygulamamızın tam haritası (Our app, end to end)

1. Kat 10Bizim uygulamamızBu bölümün konusu: bütün alt katlar tek bir dokunuşta devreye giriyor.
2. Kat 9Web ve tarayıcıİstemci tarafı: HTML, CSS, JS; mobilde aynı fikir, React Native üzerinden. Bölüm 20, 23–26, 31–33.
3. Kat 8Ağ ve internetDNS, TCP, TLS, HTTP: istek ve yanıt buradan geçer. Bölüm 19–20, 35.
4. Kat 7İşletim sistemiTelefonda ve sunucuda süreçleri, ağ bağlantısını, dosyaları yönetir. Bölüm 13–18.
5. Kat 5–6Diller ve gömülü yazılımTypeScript/JS ve Go kodu çalışabilir hâle gelir. Bölüm 9–12, 21, 30, 36.
6. Kat 0–4Donanım, makine diliHer adımın en altında hâlâ bitler, işlemci komutları ve bellek var. Bölüm 2–8.

Bu bölümde dört şey yapacağız. Önce bir cevabın yolculuğunu dokuz durakta izleyeceğiz; her durakta hangi katın çalıştığını ve hangi bölüme ait olduğunu söyleyeceğiz (45.1). Sonra aynı yolculuğu bir mimari çizim olarak tek sayfaya sığdıracağız (45.2). Üçüncü olarak, yolculuğun taşıdığı verinin ve oyunlaştırmanın (oyunlaştırma (gamification)) şeklini çizeceğiz (45.3). Son olarak, her parça için "takılırsam ne öğrenmeliyim" listesini çıkaracağız (45.4). Bu liste, Kerem'in Kısım II'den çıkarken eline alacağı pratik haritadır.

45.1 Bir cevabın yolculuğu

Senaryo: Kerem'in kullanıcısı "Hukuka Giriş" bölümünde 17 numaralı soruyu görüyor, üç şıktan ikincisine (indeks 2) dokunuyor ve "Kontrol et" düğmesine basıyor. Yarım saniye sonra ekranda yeşil bir "Doğru! +10 puan" yazısı beliriyor, seri sayacı 5'ten 5'te kalıyor (bugün zaten ilk cevap değil), puan 340'a çıkıyor ve sıralamada 12. oldu. Bu yarım saniyede ne oldu? Dokuz durakta izleyelim.

Durak 1: Parmak, cam ve işletim sistemi (Kat 0–7)

Dokunmatik ekran, parmağının elektriksel etkisini bir koordinata (x, y) çevirir. Bu yalnızca sayıdır: Bölüm 2'deki gibi, bitler. Telefonun işletim sistemi bu koordinatı alır, hangi uygulamanın hangi penceresinde olduğunu bulur ve uygulamaya bir olay olarak iletir. Sürücü ve giriş/çıkış katmanı (Bölüm 17) bu işin donanım tarafıdır; "olay" fikri ise Bölüm 26'daki click olayının mobil karşılığıdır. Sen bu durakta hiçbir şey yazmadın; iOS ve Android yazdı. Ama dokunmanın kodunun çalışması için bir süreç (Bölüm 14) olarak uygulamanın telefonun belleğinde (Bölüm 15) yüklü olması gerekir.

Durak 2: React Native bileşeni (Kat 9–10, istemci)

Uygulama React Native ile yazılmış bir bileşen (component)dir (Bölüm 31, Bölüm 32). Düğmenin onPress özelliğine bir fonksiyon bağlanmıştır; olay geldiğinde o fonksiyon çalışır. React'ın ana fikrini hatırla: ekran, durumun (state) bir fonksiyonudur. Fonksiyon durumu değiştirirse ("cevap gönderiliyor"), React ekranı yeniden çizer. TypeScript (Bölüm 30) burada sessiz bir bekçidir: cevap isteğinin şekli { questionId: number; choice: number } diye tanımlıysa, yanlışlıkla metin gönderen kod derlenmez bile.

// Taslak: ekran bileşeninin içinde (çalıştırılmadı)
const gonder = useCevapGonder();            // Durak 3'te anlatılacak
<Button title="Kontrol et" onPress={() =>
  gonder.mutate({ questionId: 17, choice: 2 })
} />

Durak 3: TanStack Query değişikliği (Kat 10, istemci)

Sunucuyla konuşan kodu doğrudan bileşene gömmek yerine, Bölüm 33'te gördüğümüz TanStack Query'nin mutasyon (mutation) mekanizması kullanılır. TanStack Query belgeleri, bir mutasyonun sunucudaki veriyi değiştiren bir işlem olduğunu ve onSuccess seçeneğiyle, sorgu istemcisinin invalidateQueries ve setQueryData yöntemleriyle birleşince güçlü bir araç olduğunu söyler.¹ Bu bize iki şey verir: istek sürerken "yükleniyor" durumunu bedavaya alırız ve cevap gelince ekrandaki puan, seri gibi "sunucu verisini" tek hamlede tazeleyebiliriz.

// Taslak (çalıştırılmadı)
function useCevapGonder() {
  const qc = useQueryClient();
  return useMutation({
    mutationFn: (g: CevapIstegi) => apiPost<CevapYaniti>("/api/answers", g),
    onSuccess: () => qc.invalidateQueries({ queryKey: ["profil"] }),
  });
}

Durak 4: fetch ve HTTP isteği (Kat 8–9)

apiPost sonunda fetch() çağırır. MDN'nin tarifine göre fetch() bir söz (Promise) döndürür; söz, sunucunun yanıtını temsil eden bir Response nesnesiyle yerine gelir ve gövdeyi JSON olarak okumak için response.json() çağrılır.² Arka planda tarayıcının (mobilde React Native'in) ağ katmanı bir HTTP isteği kurar (Bölüm 35):

POST /api/answers HTTP/1.1
Host: api.ornek-hukuk-app.com
Authorization: Bearer <belirteç>
Content-Type: application/json

{"questionId":17,"choice":2}

Gövde 28 byte (bunu len() ile saydım; Bölüm 2'deki gibi, her ASCII karakter 1 byte). Authorization başlığı, kullanıcının kim olduğunu söyleyen belirteçtir (Bölüm 41, 41.3). Alan adı api.ornek-hukuk-app.com uydurmadır; gerçek adres Bölüm 43'te anlatılan DNS kaydıyla belirlenir.

Durak 5: Ağ ve HTTPS (Kat 8)

İstek, telefondan bir yere gitmeden önce üç şey olur. Önce alan adı, DNS ile bir IP adresine çevrilir (Bölüm 19). Sonra TCP bağlantısı kurulur. Sonra TLS el sıkışması ile bağlantı şifrelenir; sertifika, karşıdakinin gerçekten o alan adının sahibi olduğunu kanıtlar (Bölüm 20, 20.4). Yani istek, yoldaki yönlendiricilerin ve kafedeki Wi-Fi'ın okuyamayacağı bir zarfın içinde gider. Parçalar paketlere bölünür, paketler yönlendiricilerden atlayarak sunucunun işletim sistemine ulaşır, sunucunun ağ katmanı onları birleştirir ve dinleyen programa, yani Go sunucumuza verir. Bu durakta senin kodun yok; ama bu durak olmasa hiçbir şey çalışmaz.

Durak 6: Go handler (Kat 5, sunucu)

Go sunucusu, standart kütüphanedeki net/http paketiyle bir adreste dinler; http.HandleFunc belirli bir yola (ör. /api/answers) bir fonksiyon bağlar.³ İstek gelince o fonksiyon, yani handler (handler), çalışır (Bölüm 37). Görevi sırayla: kimlik doğrula, gövdeyi çöz, veriyi doğrula, işi yap, yanıt yaz. Aşağıdaki program bu iskeleti sahte parçalarla gösterir; derleyip go vet ile denetledim ve çalıştırdım:

func (s *server) postAnswer(w http.ResponseWriter, r *http.Request) {
    userID := 42 // gerçekte kimlik doğrulama katmanından gelir (Bölüm 41)
    var req answerReq
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "bad json", http.StatusBadRequest)   // 400
        return
    }
    res, err := s.store.SaveAnswer(r.Context(), userID, req) // Postgres (Durak 7)
    if err != nil {
        http.Error(w, "server error", http.StatusInternalServerError) // 500
        return
    }
    if res.PointsEarned > 0 {
        if rank, err := s.board.AddScore(r.Context(), userID, res.PointsEarned); err == nil {
            res.Rank = rank                                  // Redis (Durak 8)
        }
    }
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(res)                           // JSON yanıt (Durak 9)
}

İki ince karar var. Birincisi, Store ve Board birer arayüzdür (Bölüm 27, Bölüm 44): handler Postgres'in ya da Redis'in ne olduğunu bilmez, yalnızca "cevabı kaydet" ve "puan ekle" der. Bu, test yazmayı (Bölüm 42) kolaylaştırır: gerçek veritabanı yerine sahte bir Store verirsin. İkincisi, sıralama güncellemesi başarısız olursa (err != nil) cevap yine de kaydedilmiş kalır; çünkü Redis'teki sıralama, Postgres'teki gerçeğin önbellekteki bir görüntüsüdür; kaybolursa yeniden kurulabilir. Bu düşünce biçimini Bölüm 40'da "önbellek ne zaman kaybedilebilir" sorusunda görmüştün.

Durak 7: Postgres işlemi (Kat 5, veri katmanı)

Doğru mu yanlış mı bilmek ve kaydetmek için veritabanına gidilir. Bir cevap birden çok değişiklik demektir: answers tablosuna satır eklemek, kullanıcının toplam puanını artırmak, günlük hedef ve seri alanlarını güncellemek, yanlışsa canı düşürmek. PostgreSQL belgelerinin tarifiyle, işlem (transaction) birden çok adımı tek bir hep-ya-da-hiç işlemde birleştirir; ara durumlar eşzamanlı diğer işlemlere görünmez ve bir hata olursa adımların hiçbiri veritabanını etkilemez.⁴ Banka örneğindeki "Alice'ten düş, Bob'a ekle" ikilisi bizde "cevabı yaz, puanı artır" ikilisidir: puan artıp cevap yazılmadıysa, kullanıcı hem puanı alır hem de aynı soruyu tekrar çözerek bir daha alabilir. (Bölüm 39, 39.3)

-- Taslak (çalıştırılmadı): Go tarafında tek bir işlem içinde
BEGIN;
  INSERT INTO answers (user_id, question_id, choice, correct)
       VALUES ($1, $2, $3, $4);
  UPDATE users
     SET total_points = total_points + $5,
         streak       = $6,
         last_active  = CURRENT_DATE
   WHERE id = $1
  RETURNING total_points, streak, hearts;
COMMIT;

$1, $2 gibi yer tutucular parametreli sorgudur (Bölüm 39, 39.5): kullanıcıdan gelen değerler SQL metnine yapıştırılmaz, ayrı gönderilir; böylece SQL enjeksiyonu olmaz (Bölüm 41, 41.4). Doğru cevap bilgisinin questions tablosunda sunucuda durduğuna dikkat et: istemci "doğru" demez, "ikinci şıkkı seçtim" der; doğruluğu sunucu hesaplar. İstemciye güvenirsen herkes puanını kendisi yazar.

Durak 8: Redis leaderboard (Kat 5, önbellek)

Postgres puanı doğru ve kalıcı olarak saklar. Ama "şu an kaçıncıyım?" sorusunu her istekte tüm kullanıcıları sıralayarak cevaplamak, kullanıcı sayısı arttıkça yavaşlar. Redis'in sıralı kümesi (sıralı küme (sorted set)) bunun için vardır (Bölüm 40, 40.2). Redis belgelerine göre ZINCRBY key increment member, sıralı kümedeki bir üyenin puanını artırır ve karmaşıklığı O(log N)'dir; ZRANGE komutu REV seçeneğiyle en yüksekten alçağa sıralı okur.⁵⁶

ZINCRBY leaderboard:haftalik 10 kullanici:42     # puanı 10 artır
ZRANGE  leaderboard:haftalik 0 9 REV WITHSCORES  # ilk 10 (taslak, çalıştırılmadı)

Bu iki komutun adlarını örnek olarak yazdım; hangi anahtar adının kullanılacağı bizim kararımızdır. Önemli olan: sıralama, hesaplanan bir şey değil, sürekli sıralı tutulan bir veri yapısıdır; ekleme sırasında yerini bulur (Bölüm 11'deki ağaç ve sıralı yapılar fikrinin bellek içi sürümü).

Durak 9: JSON yanıt ve ekranın değişmesi (Kat 8–10)

Go, sonucu JSON'a çevirip yazar (json.NewEncoder(w).Encode). Çalıştırdığım örnekte yanıt şuydu ve 85 byte (satır sonu dahil) tuttu:

HTTP 200
{"correct":true,"pointsEarned":10,"totalPoints":340,"streak":5,"hearts":3,"rank":12}

Yanıt aynı şifreli bağlantıdan geri döner, telefonun ağ katmanı onu birleştirir, fetch'in sözü yerine gelir, TanStack Query onSuccess'i çağırır, "profil" sorgusunu geçersiz kılar (yenilenir), React durumun değiştiğini görür ve ekranı yeniden çizer: yeşil "Doğru! +10" ve yeni puan. Dokunuştan bu ana kadar geçen süre, iyi bir ağda genellikle bir saniyenin altındadır; bunun büyük kısmı ağın ışık hızıyla ilgili gecikmesidir (Bölüm 19), Go ve veritabanı kısmı çoğunlukla milisaniyelerdir.

Dokuz durağa baktığında bir örüntü fark etmelisin: her durak bir alt katın sunduğu imkânı kullanır ve bir üst kata daha basit bir şey sunar. Go handler'ı yazan kişi paketlerin nasıl yönlendirildiğini düşünmez (Durak 5 onu gizler); React bileşenini yazan kişi TCP'yi düşünmez. Kat planının işe yaradığı yer burasıdır: bir hata olduğunda, hatanın hangi durakta olduğunu bulmak, çözümün yarısıdır.

45.2 Mimari çizim: hangi parça nerede çalışır

Yolculuğu dokuz durak olarak anlattık. Şimdi aynı şeyi bir harita olarak çizelim: hangi parça hangi bilgisayarda çalışır? Bu soru Bölüm 44'ün "mimari" kelimesinin somut hâli: değiştirmesi pahalı kararlar, yani parçaların yerleri ve aralarındaki sınırlar.

  KULLANICININ TELEFONU                      İNTERNET                    SUNUCU (bulutta) 
 ┌───────────────────────────┐                                 ┌────────────────────────────────────┐
 │ Expo / React Native (TS)  │                                 │ Go programı (tek süreç, monolit)   │
 │  ├ ekranlar (bileşenler)  │      HTTPS (DNS+TCP+TLS)        │  ├ HTTP katmanı (handler'lar)      │
 │  ├ TanStack Query         │ ───── POST /api/answers ──────► │  ├ iş mantığı (puan, seri, can)    │
 │  │   (sunucu verisi       │       JSON, belirteç            │  └ veri katmanı ──┐   ┌─────────┐   │
 │  │    önbelleği)          │ ◄──── 200 + JSON ────────────── │        │          │   │         │   │
 │  └ fetch                  │                                 └────────┼──────────┼───┼─────────┼───┘
 └───────────────────────────┘                                          ▼          ▼   ▼         ▼
                                                                  ┌────────────┐  ┌────────────┐
   Geliştirici tarafı:  Git (worktree) ─ agent'lar ─ AGENTS.md    │ PostgreSQL │  │   Redis    │
   test, CI, konteyner → yayın (Bölüm 42–43)                      │ gerçek veri│  │ sıralama   │
                                                                  │ (kalıcı)   │  │ (önbellek) │
                                                                  └────────────┘  └────────────┘

Çizimden okunacak beş şey:

1. Üç ayrı bilgisayar türü var: kullanıcının telefonu (senin kontrolünde değil, yüz binlerce farklı cihaz), sunucu (senin kontrolünde, kiralanan makine ya da konteyner) ve ikisinin arasındaki internet (kimsenin kontrolünde değil). Güvenlik düşüncesi bu üçlüden doğar: telefona asla güvenme (Bölüm 41), internete "şifreli zarf" olmadan bir şey emanet etme (Bölüm 20).
2. Sunucuda tek bir Go programı var: Bölüm 44'ün diliyle monolit ya da daha doğrusu modüler monolit. Mikroservis yok. İki kişilik, agent'larla çalışan bir ekip için bu akıllıca bir başlangıçtır; çünkü her ek servis, ağ hatası, ayrı yayın ve ayrı izleme demektir.
3. Katmanlı iç yapı: HTTP katmanı (istek–yanıt ve JSON), iş mantığı (puan nasıl hesaplanır, seri ne zaman sıfırlanır) ve veri katmanı (SQL ve Redis komutları). Bir katman yalnızca altındakini çağırır. Seri kuralını değiştirmek istersen, yalnızca iş mantığı katmanına dokunursun; ekran ve SQL aynı kalır.
4. Postgres gerçeğin kaynağıdır, Redis ise hız içindir: Redis'i kaybedersen leaderboard'u Postgres'teki puanlardan yeniden kurarsın; Postgres'i kaybedersen kullanıcıların her şeyini kaybedersin. Bu yüzden Postgres için yedekleme (Bölüm 39, 39.6) hayati, Redis için nispeten gevşektir.
5. Geliştirici tarafı çizimin altında: Git, test, CI ve yayın hattı kullanıcıya görünmez ama kodun telefona ve sunucuya nasıl ulaştığını belirler (Bölüm 28, Bölüm 42, Bölüm 43). Bölüm 46'da agent'lar bu hattın başına otururlar.

45.3 Bölüm tasarımı, oyunlaştırma ve verinin şekli

Yolculuğun taşıdığı veri nereden geliyor ve neye benziyor? Bir öğrenme uygulamasının kalbi, içerik modelidir: kullanıcıya ne gösterdiğimiz ve onun etkileşimini nasıl kaydettiğimiz. Bölüm 38'de şema tasarımını (kullanıcılar, bölümler, sorular, cevaplar) kavramsal olarak çizdin; burada aynı şemayı uygulamanın dilinde okuyalım.

İçerik: bölüm, soru, şık

Bir hukuk dersi uygulamasında içerik hiyerarşik olur: Ünite (ör. "Hukuka Giriş") altında bölümler (ör. "Hukuk kuralı nedir?"), her bölümün altında kısa sorular, her sorunun altında şıklar. Hiyerarşi bir ağaçtır (Bölüm 11) ve ilişkisel veritabanında yabancı anahtarlarla ifade edilir (Bölüm 38, 38.2): bir soru section_id ile bir bölüme, bir şık question_id ile bir soruya bağlıdır. Soru metinleri ve şıklar kullanıcıdan bağımsız, herkes için aynıdır; kullanıcıya özel olan yalnızca cevaplar ve onlardan türeyen puan, seri ve can durumudur.

-- Taslak şema (Postgres sözdizimi; çalıştırılmadı)
CREATE TABLE users (
  id            bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  display_name  text    NOT NULL,
  total_points  integer NOT NULL DEFAULT 0,
  streak        integer NOT NULL DEFAULT 0,
  last_active   date,
  hearts        integer NOT NULL DEFAULT 5
);
CREATE TABLE sections  (id bigint PRIMARY KEY, title text NOT NULL, position integer NOT NULL);
CREATE TABLE questions (id bigint PRIMARY KEY, section_id bigint REFERENCES sections(id),
                        body text NOT NULL, correct_choice integer NOT NULL);
CREATE TABLE answers   (id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
                        user_id bigint REFERENCES users(id),
                        question_id bigint REFERENCES questions(id),
                        choice integer NOT NULL, correct boolean NOT NULL,
                        answered_at timestamptz NOT NULL DEFAULT now());

Şemada iki karar öğretici. correct_choice sorular tablosunda durur; istemciye gönderilmez (yoksa kullanıcı ağ isteğini inceleyip doğru şıkkı okur; Bölüm 41). Ve answers her cevabı saklar, yalnızca "sonuç"u değil: geçmişi saklamak, sonradan "hangi soru en çok yanlış yapılıyor?" gibi soruları cevaplamayı mümkün kılar. Verinin şekline karar verirken genel kural: bugün sormak istemediğin ama yarın sormak isteyebileceğin şeyi atma; ama ihtiyacın olmayan yığınlarca şeyi de saklama.

Oyunlaştırma: puan, seri, can, leaderboard

Oyunlaştırma (gamification), oyun mekaniklerini (puan, rozet, sıralama, seri) oyun olmayan bir bağlama, burada öğrenmeye, taşımaktır. Duolingo benzeri bir uygulamanın dört temel mekaniği ve her birinin teknik karşılığı şöyle:

Seri hesabı güzel bir küçük örnektir; çünkü basit görünür ama tarih mantığı gerektirir. Kural: bugün zaten cevap verildiyse seri aynı kalır; son cevap dündüyse seri bir artar; daha eskiyse seri 1'e döner. Bu kuralı Python ile yazıp 13 Kasım 2026 "bugün" kabul edilerek denedim:

son cevap      önceki seri   yeni seri
2026-11-13         5            5     (bugün zaten cevaplamış)
2026-11-12         5            6     (dün: seri sürüyor)
2026-11-10         5            1     (iki gün boşluk: seri koptu)
hiç yok            0            1     (ilk cevap)

Bu kuralın nerede yaşadığı bir mimari sorudur. Eğer kural telefonda hesaplanırsa, kullanıcı saatini ileri alarak seriyi şişirebilir; bu yüzden hesap sunucuda yapılır ve "hangi gün"ün hangi saat dilimine göre sayıldığı açıkça belirlenir. Hukuk okumuş biri için tanıdık bir ilke: tarih ve süre hesabını tarafların beyanına değil, tek bir yetkili kayda göre yaparsın. Burada yetkili kayıt sunucunun saatidir.

Verinin yolculuktaki şekli

Aynı bilgi yolculuk boyunca beş farklı biçimde yaşar. Telefonda TypeScript nesnesi (Bölüm 25, Bölüm 30); ağda JSON metni (UTF-8 byte'ları, Bölüm 2); Go'da struct (Bölüm 36); Postgres'te tablo satırı; Redis'te sıralı kümede (üye, puan) çifti. Her sınırı geçerken bir dönüşüm olur (nesneyi JSON'a çevir, JSON'u struct'a çöz, struct'ı SQL parametrelerine ver). Hataların büyük kısmı bu dönüşüm sınırlarında doğar: alan adı büyük–küçük harf farkı (questionId ile question_id), sayının metin olarak gelmesi, tarihin saat dilimi. Bölüm 2'deki ilke burada tekrar çalışır: anlam bağlamdadır; aynı değeri her kat kendi kuralıyla okur.

45.4 Neyi bilmeden sürüklenmezsin

Bu kitabın amacı seni her parçada uzman yapmak değil; anlamadığın bir şeyin seni sürüklemesini engellemektir. Aşağıdaki liste, her parça için "bir şey ters giderse en az neyi bilmem lazım" sorusunun cevabıdır. Hepsini ezberleme; takıldığın zaman bu tabloya dön, doğru bölüme git.

Tabloyu ikinci bir şekilde de okuyabilirsin: "belirti" sütunu hangi katta aramaya başlayacağını söyler. Bir agent "500 hatası alıyorum" dediğinde, 500 sunucu hatasıdır; yani sorun telefonda değildir, Durak 6–8 arasındadır. "Eski puan görünüyor" derse, sunucu muhtemelen doğru çalışmıştır, TanStack'in önbelleği tazelenmemiştir (Durak 9). Haritayı bilmek, soruyu doğru yere yönlendirmeyi sağlar.

Bir hata ayıklama ritmi

Katlı yapılarda hata ayıklamanın sağlam bir ritmi vardır: ikiye böl. Dokuz durağı tek tek yoklamak yerine ortadan başla: "sunucuya istek ulaşıyor mu?" (sunucu log'u). Ulaşıyorsa sorun Durak 6 ve sonrasındadır; ulaşmıyorsa Durak 1–5. Bu, Bölüm 1'deki telefon rehberinde "ortadan böl" yönteminin, ve Bölüm 11'de ikili aramanın, bire bir aynısıdır. Dokuz durak yaklaşık dört soruda tek bir durağa iner (2⁴ = 16 ≥ 9).

Bu bölümde neler kuruldu

Bir cevabın yolculuğunu dokuz durakta izledik: dokunuş ve işletim sistemi olayı, React Native bileşeni, TanStack Query mutasyonu, fetch ile HTTP isteği, DNS+TCP+TLS ile şifreli taşıma, Go handler, Postgres işlemi, Redis sıralı küme güncellemesi ve JSON yanıtla ekranın yenilenmesi. Mimariyi üç bilgisayar türüyle (telefon, internet, sunucu) ve sunucu içinde katmanlarla (HTTP, iş mantığı, veri) çizdik; Postgres'i gerçeğin kaynağı, Redis'i hız önbelleği olarak ayırdık. Verinin şeklini (ünite–bölüm–soru–şık hiyerarşisi, kullanıcı ve cevap kayıtları) ve oyunlaştırma mekaniklerinin (puan, seri, can, leaderboard) teknik karşılıklarını gördük; seri kuralını çalıştırarak doğruladık. Son olarak her parça için "takılırsam ne öğrenmeliyim" tablosunu ve ikiye bölerek hata ayıklama ritmini çıkardık.

Terimler sözlükte, Bölüm 45 başlığı altında.

Kaynaklar

1. TanStack Query belgeleri, Mutations: mutasyon kavramı, onSuccess, invalidateQueries, setQueryData.
2. MDN, Using the Fetch API: fetch() bir Promise döndürür, Response nesnesi, JSON okuma.
3. Go, net/http paket belgesi: HandleFunc, ListenAndServe. Bölümdeki Go taslağı bu paketle derlenip çalıştırıldı (go vet ve go run, Go 1.27.2).
4. PostgreSQL belgeleri, Tutorial: Transactions: işlemin hep-ya-da-hiç olması, ara durumların diğer işlemlere görünmemesi.
5. Redis belgeleri, ZINCRBY: sıralı kümede üyenin puanını artırır, O(log N).
6. Redis belgeleri, ZRANGE: REV seçeneği, WITHSCORES.