কনকারেন্সি হাতে-কলমে: থ্রেড A, থ্রেড B আর একটা শেয়ার্ড কাউন্টার

একই সময়-জানালায় অনেকগুলো কাজ এগিয়ে চলে, যদিও ঠিক একই মুহূর্তে সবগুলো চলছে না।

একটা CPU কোর এক মুহূর্তে একটাই ইনস্ট্রাকশন চালায়। কিন্তু অপারেটিং সিস্টেম কয়েক মিলিসেকেন্ড পর পর কাজ বদলায় (context switch)। এত দ্রুত বদলায় যে মনে হয় সব একসাথে চলছে।

এর আসল লাভ আসে অপেক্ষার সময়ে। একটা ওয়েব সার্ভার যখন ডেটাবেসের উত্তরের জন্য ৫০ms বসে থাকে, সেই সময়ে CPU অন্য রিকোয়েস্ট সামলাতে পারে। কনকারেন্সি ছাড়া প্রতিটা ইউজারকে আগের জনের কাজ শেষ হওয়া পর্যন্ত অপেক্ষা করতে হতো।

মনে রাখো: কনকারেন্সি হলো প্রোগ্রামের গঠন, অর্থাৎ কাজগুলোকে আলাদা আলাদা স্বাধীন অংশে ভাগ করা। সেগুলো আসলে একসাথে চলবে কিনা, সেটা হার্ডওয়্যারের ব্যাপার।

কনকারেন্সি মানে পালা করে চালানো (interleaving)। প্যারালেলিজম মানে একাধিক কোরে সত্যিই একই মুহূর্তে চালানো।

Go ভাষার অন্যতম স্রষ্টা Rob Pike-এর কথায়: "Concurrency is about dealing with lots of things at once." প্যারালেলিজম হলো অনেক কাজ একসাথে করা। একটা ভালো কনকারেন্ট ডিজাইন বেশি কোর পেলে প্যারালেলও চলতে পারে।

মনে রাখো: Go-তে একই কোড দুটোই পায়। Go runtime সব goroutine-কে GOMAXPROCS সংখ্যক OS থ্রেডে চালায় (ডিফল্ট = CPU কোরের সংখ্যা)। ১টা কোরে goroutine-গুলো পালা করে চলে (কনকারেন্সি), ৮টা কোরে সত্যিই একসাথে চলে (প্যারালেলিজম)। কোড বদলাতে হয় না।

প্রসেস আলাদা ও ভারী। থ্রেড হালকা, মেমোরি শেয়ার করে, আর সেজন্যই ঝুঁকিপূর্ণ।

প্রতিটা প্রসেস নিজের আলাদা মেমোরি পায়। একটা প্রসেস আরেকটার ভেরিয়েবল ছুঁতে পারে না। একটা প্রসেসের ভেতরে একাধিক থ্রেড থাকে। তারা heap মেমোরি, খোলা ফাইল, গ্লোবাল ভেরিয়েবল সব শেয়ার করে। প্রত্যেকের শুধু নিজের stack আর register আলাদা।

Go-র goroutine থ্রেডের চেয়েও হালকা। একটা goroutine শুরু হয় মাত্র কয়েক KB stack নিয়ে, দরকার হলে বাড়ে। Go runtime হাজার হাজার goroutine-কে অল্প কয়েকটা OS থ্রেডে ভাগ করে চালায় (M:N scheduling)। তবে মেমোরি শেয়ার করার ঝুঁকি থ্রেডের মতোই।

একটা থ্রেড জন্ম থেকে শেষ পর্যন্ত কয়েকটা অবস্থার (state) মধ্য দিয়ে যায়।

• New: থ্রেড অবজেক্ট বানানো হয়েছে, start() ডাকা হয়নি।
• Runnable: চলতে প্রস্তুত, শিডিউলারের লাইনে অপেক্ষা করছে।
• Running: এই মুহূর্তে কোনো কোরে চলছে।
• Blocked: একটা লক চাইছে যেটা অন্য কেউ ধরে আছে।
• Waiting: কারো সংকেতের (signal, join(), I/O) অপেক্ষায় ঘুমিয়ে আছে। টাইমআউটসহ হলে Java একে বলে TIMED_WAITING।
• Terminated: কাজ শেষ বা exception-এ মারা গেছে। আর চালু করা যায় না।

মনে রাখো: production-এ থ্রেড ডাম্প (Java-তে jstack, Go-তে pprof-এর goroutine প্রোফাইল বা চলন্ত প্রোগ্রামে kill -QUIT) নিলে অনেক থ্রেড BLOCKED দেখলে বুঝবে লক নিয়ে কাড়াকাড়ি চলছে। এটা পারফরম্যান্স সমস্যা খোঁজার প্রথম সূত্র।

দুটো থ্রেড কোনো সমন্বয় ছাড়া শেয়ার্ড ডেটা বদলায়, আর ফলাফল নির্ভর করে কে আগে পৌঁছাল তার উপর।

balance += 100 দেখতে এক লাইন, কিন্তু CPU-র কাছে তিনটা ধাপ: মেমোরি থেকে পড়ো, যোগ করো, মেমোরিতে লেখো। দুটো থ্রেড একসাথে এটা করলে এমন হতে পারে:

দুজনেই ১০০ টাকা জমা দিল, কিন্তু একজনের টাকা হারিয়ে গেল। একে বলে lost update। উপরের ডেমোর লাল W ঠিক এটাই দেখায়।

আরেকটা সাধারণ রূপ হলো check-then-act: "সিট খালি আছে? তাহলে বুক করো।" দুজন একসাথে চেক করে দুজনেই খালি দেখে, তারপর দুজনেই একই সিট বুক করে।

মনে রাখো: রেস কন্ডিশন সবসময় দেখা দেয় না। টেস্টে ১০০০ বার পাস করে প্রোডাকশনে লোড বাড়লে হঠাৎ ভুল হয়। সমাধান তিন রকম: লক দিয়ে পাহারা দাও, atomic অপারেশন ব্যবহার করো, অথবা ডেটা শেয়ারই কোরো না।

একটা থ্রেড critical section-এ ঢোকে, বাকিরা দরজায় অপেক্ষা করে।

Critical section হলো কোডের সেই অংশ যেটা শেয়ার্ড ডেটা ছোঁয়। Mutex একটা তালার মতো। যে থ্রেড তালা নেয় (lock/acquire), শুধু সে-ই ভেতরে যায়। কাজ শেষে তালা ছেড়ে দেয় (unlock/release), তখন অপেক্ষারত একজন ঢোকে।

var (
    mu      sync.Mutex
    balance = 500
)

func deposit(amount int) {
    mu.Lock()
    defer mu.Unlock()          // ফাংশন থেকে বের হলেই unlock, panic হলেও
    current := balance
    balance = current + amount
}

মনে রাখো: Lock()-এর ঠিক পরের লাইনেই defer Unlock() লেখো। মাঝপথে exception হয়ে লক না ছাড়লে বাকি সব থ্রেড চিরকাল আটকে থাকবে। আর লকের ভেতরে যত কম কাজ করা যায় তত ভালো, বিশেষ করে নেটওয়ার্ক কল কখনোই না।

ক্যাপাসিটিসহ mutex। একসাথে N সংখ্যক থ্রেডকে একটা রিসোর্স ব্যবহার করতে দেয়।

Semaphore ভেতরে একটা কাউন্টার রাখে। acquire() কাউন্টার এক কমায়; শূন্য হলে পরের জনকে অপেক্ষা করতে হয়। release() কাউন্টার এক বাড়ায় এবং অপেক্ষারত একজনকে জাগায়।

// buffered channel = semaphore; একসাথে সর্বোচ্চ ১০টা DB query
var dbSlots = make(chan struct{}, 10)

func runQuery(q string) (*sql.Rows, error) {
    dbSlots <- struct{}{}            // acquire: ১০টা ভর্তি থাকলে এখানে অপেক্ষা
    defer func() { <-dbSlots }()     // release
    return db.Query(q)
}

• ডেটাবেস কানেকশন পুল, যাতে DB-তে অতিরিক্ত চাপ না পড়ে।
• থার্ড-পার্টি API-তে একসাথে সর্বোচ্চ ৫টা রিকোয়েস্ট।
• একসাথে কতগুলো ফাইল ডাউনলোড চলবে তার সীমা।

মনে রাখো: mutex-এর একজন মালিক থাকে, যে লক নিয়েছে শুধু সে-ই ছাড়তে পারে। Semaphore-এর কোনো মালিক নেই, যেকোনো থ্রেড release করতে পারে। Go-তে আলাদা semaphore টাইপ লাগে না, buffered channel-ই যথেষ্ট। ওজনসহ semaphore লাগলে (যেমন বড় কাজ ৩টা স্লট নেবে) golang.org/x/sync/semaphore প্যাকেজ আছে।

একটা থ্রেড ঘুমিয়ে থাকে যতক্ষণ না আরেকটা থ্রেড জানায় যে কোনো শর্ত এখন সত্য হয়েছে।

ধরো consumer থ্রেড কিউ থেকে কাজ নেবে, কিন্তু কিউ খালি। বারবার for len(items) == 0 {} চালালে CPU পুড়বে (busy waiting)। Condition variable দিয়ে থ্রেড ঘুমিয়ে পড়ে, আর producer কাজ রেখে তাকে ডেকে তোলে।

var (
    mu    sync.Mutex
    cond  = sync.NewCond(&mu)
    items []string
)

func consume() string {
    mu.Lock()
    defer mu.Unlock()
    for len(items) == 0 {      // if নয়, for লুপ!
        cond.Wait()            // লক ছেড়ে ঘুমায়, জাগলে আবার লক নেয়
    }
    x := items[0]
    items = items[1:]
    return x
}

func produce(x string) {
    mu.Lock()
    items = append(items, x)
    mu.Unlock()
    cond.Signal()              // একজন অপেক্ষারতকে জাগাও
}

মনে রাখো: Wait() সবসময় for লুপে রাখো। থ্রেড কখনো কারণ ছাড়াই জেগে উঠতে পারে (spurious wakeup), আবার কখনো জাগার আগেই অন্য কেউ আইটেমটা নিয়ে যায়। জেগে আবার শর্ত চেক করতেই হবে। বাস্তবে Go-তে sync.Cond কমই লাগে, কারণ channel থেকে পড়া (<-ch) নিজেই এই অপেক্ষা আর জাগানোর কাজ করে।

বড় একটা লক সহজ কিন্তু ধীর। অনেক ছোট লক ভালো স্কেল করে, কিন্তু সেগুলো নিয়ে চিন্তা করা কঠিন।

Coarse-grained: পুরো ক্যাশ বা পুরো HashMap-এর জন্য একটা লক। কোড সহজ, ভুলের সুযোগ কম। কিন্তু ১০০টা থ্রেড ১০০টা আলাদা key পড়তে চাইলেও লাইনে দাঁড়াতে হয়।

Fine-grained: প্রতিটা bucket বা প্রতিটা রেকর্ডের জন্য আলাদা লক। ভিন্ন key-তে কাজ করা থ্রেডরা একে অপরকে আটকায় না। Java-র পুরনো ConcurrentHashMap ম্যাপটাকে ১৬টা segment-এ ভাগ করে আলাদা লক রাখত (lock striping)।

মনে রাখো: লক যত বেশি, ডেডলকের সম্ভাবনা তত বেশি, কারণ থ্রেডকে একসাথে একাধিক লক নিতে হতে পারে। শুরু করো coarse দিয়ে, প্রোফাইল করে দেখো সত্যিই লকে প্রতিযোগিতা (contention) হচ্ছে কিনা, তারপর ভাঙো।

একই থ্রেড একই লক একাধিকবার নিরাপদে নিতে পারে।

সাধারণ লক যে থ্রেড ধরে আছে, সে আবার সেটা চাইলে নিজেই নিজের জন্য অপেক্ষা করবে, অর্থাৎ নিজের সাথে ডেডলক। Reentrant লক মনে রাখে কোন থ্রেড মালিক এবং কতবার নিয়েছে (hold count)। যতবার নেবে ততবার ছাড়তে হবে, কাউন্ট শূন্য হলে তবেই লক মুক্ত হয়।

Go-র sync.Mutex ইচ্ছে করেই reentrant নয়। Go টিমের যুক্তি: reentrant লক লুকিয়ে ফেলে যে ডেটা কখন অর্ধেক-বদলানো অবস্থায় আছে। তাই Go-তে একই লক দুবার নিলে নিজের সাথেই deadlock হয়। সমাধান হলো কোডটা দুই ভাগ করা: বাইরের পাবলিক মেথড লক নেয়, ভেতরের ...Locked মেথড ধরে নেয় লক আগেই নেওয়া আছে।

type Bank struct{ mu sync.Mutex }

func (b *Bank) Transfer(from, to *Account, amt int) {
    b.mu.Lock()
    defer b.mu.Unlock()
    b.withdrawLocked(from, amt)  // b.Withdraw() ডাকলে আবার Lock() → নিজের সাথে deadlock
    b.depositLocked(to, amt)
}

func (b *Bank) Withdraw(acc *Account, amt int) {
    b.mu.Lock()
    defer b.mu.Unlock()
    b.withdrawLocked(acc, amt)
}

// নিয়ম: ...Locked মেথড ডাকার আগে caller লক নিয়ে রাখবে
func (b *Bank) withdrawLocked(acc *Account, amt int) { acc.Balance -= amt }
func (b *Bank) depositLocked(acc *Account, amt int)  { acc.Balance += amt }

মনে রাখো: Java-র synchronized আর Python-এর RLock reentrant, Go-র sync.Mutex নয়। এক ভাষা থেকে আরেক ভাষায় গেলে এই পার্থক্য থেকে প্রায়ই অদ্ভুত deadlock হয়। ইন্টারভিউতে "Go-তে reentrant লক নেই কেন?" প্রশ্নটা আসে।

থ্রেড A অপেক্ষা করছে B-এর জন্য, B অপেক্ষা করছে A-এর জন্য। কেউ নড়ে না।

ডেডলক হতে চারটা শর্ত (Coffman conditions) একসাথে সত্য হতে হয়:

• Mutual exclusion: রিসোর্স একবারে একজনই ব্যবহার করতে পারে।
• Hold and wait: একটা ধরে রেখে আরেকটার জন্য অপেক্ষা।
• No preemption: জোর করে কারো কাছ থেকে লক কেড়ে নেওয়া যায় না।
• Circular wait: অপেক্ষার একটা বৃত্ত তৈরি হয়।

যেকোনো একটা ভাঙলেই ডেডলক অসম্ভব। বাস্তবে সবচেয়ে সহজ হলো lock ordering: সব থ্রেড সবসময় একই ক্রমে লক নেবে (যেমন অ্যাকাউন্ট আইডি ছোট থেকে বড়)। তাহলে বৃত্ত তৈরি হতেই পারে না। আরেকটা উপায় হলো timeout দিয়ে লক চাওয়া (tryLock), না পেলে সব ছেড়ে দিয়ে আবার চেষ্টা।

থ্রেডগুলো একে অপরের প্রতি সাড়া দিতে থাকে, সক্রিয় থাকে, কিন্তু আসল কোনো কাজ শেষ হয় না।

ডেডলকে থ্রেডরা ঘুমিয়ে থাকে, CPU খরচ শূন্য। লাইভলকে তারা পুরো দমে চলছে, CPU ১০০%, কিন্তু অগ্রগতি শূন্য। এটা প্রায়ই হয় ডেডলক এড়ানোর "ভদ্র" কোড থেকে: "লক না পেলে আমার লক ছেড়ে দিয়ে আবার চেষ্টা করি।" দুই থ্রেড একই ছন্দে এটা করলে চিরকাল ছাড়ে আর ধরে।

মনে রাখো: সমাধান হলো র‍্যান্ডম অপেক্ষা (randomized backoff)। প্রত্যেকে আবার চেষ্টার আগে একটা র‍্যান্ডম সময় অপেক্ষা করে, ফলে ছন্দ ভেঙে যায়। Ethernet-এর collision সামলানো আর API retry-র exponential backoff with jitter এই ধারণা থেকেই এসেছে।

বাকিরা এগিয়ে যাচ্ছে, কিন্তু একটা থ্রেড বারবার CPU বা লক পাওয়া থেকে বঞ্চিত হচ্ছে।

সিস্টেম সামগ্রিকভাবে চলছে, তাই এটা ধরা কঠিন। কারণগুলো সাধারণত:

• Unfair লক: লক ছাড়ার সাথে সাথে যে প্রথম ধরতে পারে সে পায়। নতুন আসা থ্রেড বারবার জিতে যায়, পুরনোটা অপেক্ষাতেই থাকে।
• Priority: উচ্চ priority-র কাজ অবিরাম আসতে থাকলে নিচের priority-র কাজ কখনো সুযোগ পায় না।
• Reader-writer লক: পাঠক অবিরাম আসতে থাকলে লেখক কখনো লক পায় না (writer starvation)।

মনে রাখো: সমাধান হলো fairness: FIFO ক্রমে লক দেওয়া (Java-তে new ReentrantLock(true)), অথবা aging, অর্থাৎ যত বেশি অপেক্ষা তত priority বাড়ানো। Go-র sync.Mutex এটা নিজেই সামলায়: কোনো goroutine ১ms-এর বেশি অপেক্ষা করলে mutex "starvation mode"-এ চলে যায় আর লাইনের ক্রমে লক দেয়। Fair লক কিছুটা ধীর, তাই Go শুধু দরকারের সময় এই মোড চালু করে।

ছোট অপারেশন যেটা পুরোটা হয় অথবা একেবারেই হয় না। মাঝপথে কেউ বাধা দিতে পারে না।

CPU-তে বিশেষ ইনস্ট্রাকশন আছে যেটা পড়া-বদলানো-লেখা এক ধাপে করে। সবচেয়ে গুরুত্বপূর্ণটা হলো CAS (Compare-And-Swap): "মান যদি এখনো 5 থাকে তবেই 6 বানাও, নইলে ব্যর্থ হও।" ব্যর্থ হলে থ্রেড নতুন মান পড়ে আবার চেষ্টা করে। কোনো লক লাগে না, কেউ ঘুমায় না।

var views atomic.Int64
views.Add(1)                      // থ্রেড-সেফ, লক ছাড়া

// CAS নিজে হাতে: মান এখনো old থাকলে তবেই old-1 বানাও
var stock atomic.Int64
func takeOne() bool {
    for {
        old := stock.Load()
        if old == 0 {
            return false          // স্টক শেষ
        }
        if stock.CompareAndSwap(old, old-1) {
            return true           // সফল
        }
        // মাঝখানে অন্য কেউ বদলে ফেলেছে, আবার চেষ্টা
    }
}

-- SQL: এক স্টেটমেন্টে চেক আর আপডেট, তাই রেস নেই
UPDATE products SET stock = stock - 1
WHERE id = 42 AND stock > 0;

-- Redis-এ একই কাজ: INCR page:home:views

মনে রাখো: দুটো atomic অপারেশন পাশাপাশি রাখলে পুরোটা atomic হয় না। if views.Load() < 10 { views.Add(1) }-এর মাঝখানে অন্য থ্রেড ঢুকতে পারে। একটা ভ্যারিয়েবলের জন্য atomic যথেষ্ট, একাধিক ভ্যারিয়েবল একসাথে বদলাতে লক লাগবে।

প্রতিটা কাজের জন্য নতুন থ্রেড না বানিয়ে নির্দিষ্ট কয়েকটা worker থ্রেড বারবার ব্যবহার করা।

থ্রেড বানানো সস্তা নয়। প্রতিটা থ্রেডের নিজস্ব stack লাগে (Java-তে সাধারণত ১MB পর্যন্ত reserve হয়), আর OS-কে kernel কল করতে হয়। প্রতি রিকোয়েস্টে নতুন থ্রেড বানালে ১০,০০০ রিকোয়েস্টে সার্ভার মেমোরি শেষ হয়ে crash করবে। Thread pool সীমা টেনে দেয়: ধরো ২০টা worker, বাকি কাজ কিউতে অপেক্ষা করবে।

Go-তে goroutine সস্তা, তাই থ্রেড বানানোর খরচ নিয়ে চিন্তা কম। কিন্তু সীমা তবুও লাগে, কারণ ডেটাবেস কানেকশন, বাইরের API-র rate limit আর মেমোরি সীমিত। Go-তে একে বলে worker pool:

jobs := make(chan string)
var wg sync.WaitGroup

for w := 0; w < 20; w++ {         // ২০টা worker goroutine
    wg.Add(1)
    go func() {
        defer wg.Done()
        for url := range jobs {    // কাজ না থাকলে অপেক্ষা, close হলে বের হয়
            fetch(url)
        }
    }()
}
for _, u := range urls {
    jobs <- u
}
close(jobs)                        // আর কাজ আসবে না
wg.Wait()                          // সব worker শেষ হওয়া পর্যন্ত অপেক্ষা

কয়টা থ্রেড রাখবে?

• CPU-bound: মোটামুটি কোরের সংখ্যার সমান। বেশি দিলে শুধু context switch বাড়ে।
• I/O-bound: কোর × (১ + অপেক্ষার সময় ÷ কাজের সময়)। ধরো ৮ কোর, প্রতি কাজে ৯০ms অপেক্ষা আর ১০ms CPU, তাহলে ৮ × (১ + ৯) = ৮০টা থ্রেড।

মনে রাখো: Java-র Executors.newFixedThreadPool() ভেতরে unbounded কিউ ব্যবহার করে। কাজ যত দ্রুত আসে তত দ্রুত শেষ না হলে কিউ বাড়তেই থাকে, শেষে OutOfMemoryError। Go-তে একই ভুলের রূপ হলো for _, u := range urls { go fetch(u) }: ১০ লাখ URL মানে ১০ লাখ goroutine একসাথে। প্রোডাকশনে সবসময় সীমা দাও (প্রজেক্ট B5 দেখো)।

এক পক্ষ কাজ তৈরি করে, আরেক পক্ষ সেটা প্রসেস করে। মাঝের কিউটাই আসল খেলোয়াড়।

কিউ দুই পক্ষকে আলাদা (decouple) করে দেয়। Producer জানে না কে প্রসেস করবে, consumer জানে না কাজ কোথা থেকে এল। দুই পক্ষ নিজের গতিতে চলে, আর আলাদাভাবে স্কেল করা যায়: চাপ বাড়লে শুধু consumer বাড়াও।

কিউ ডিজাইনের সময় তিনটা প্রশ্নের উত্তর দিতে হয়:

• কিউ ভর্তি হলে কী হবে? producer অপেক্ষা করবে, নতুন কাজ ফেলে দেবে, নাকি error দেবে?
• ক্রম কি জরুরি? একটা অর্ডারের "তৈরি" ইভেন্ট "বাতিল" ইভেন্টের আগে প্রসেস হতে হবে কি?
• consumer মাঝপথে মারা গেলে? কাজটা হারাবে, নাকি আবার কিউতে ফিরবে (acknowledgement)?

মনে রাখো: consumer থামানোর পরিষ্কার উপায় হলো poison pill: কিউতে একটা বিশেষ মান রাখো যেটা দেখে consumer বুঝবে কাজ শেষ। Go-তে এর জন্য আছে close(ch)। চ্যানেল বন্ধ হলে for x := range ch লুপ নিজে থেকেই শেষ হয়, যত consumer-ই থাকুক। শুধু মনে রাখো, চ্যানেল বন্ধ করবে producer, consumer নয়।

Blocking মানে কাজ শেষ না হওয়া পর্যন্ত বসে থাকা। Non-blocking মানে সাথে সাথে ফিরে আসা, পরে আবার দেখা।

Blocking কলে (যেমন সাধারণ socket.recv()) ডেটা না আসা পর্যন্ত থ্রেড ঘুমিয়ে থাকে। কোড সহজ, কিন্তু ১০,০০০ কানেকশনের জন্য ১০,০০০ থ্রেড লাগে।

Non-blocking কল সাথে সাথে ফেরে: "ডেটা আছে, এই নাও" অথবা "এখনো নেই"। একটা event loop OS-কে জিজ্ঞেস করে (Linux-এ epoll) কোন কানেকশন প্রস্তুত, তারপর শুধু সেগুলো সামলায়। এভাবে একটা থ্রেড হাজার হাজার কানেকশন চালায়। Node.js, Nginx, Python-এর asyncio এভাবেই কাজ করে।

Go দুটোর সুবিধা একসাথে দেয়। তুমি সাধারণ blocking কোড লেখো (conn.Read()), কিন্তু ভেতরে Go runtime epoll দিয়ে non-blocking I/O করে। কোনো goroutine অপেক্ষায় থাকলে runtime সেই OS থ্রেডে অন্য goroutine চালায়। আর চ্যানেলে নিজে থেকে non-blocking কাজ করতে চাইলে আছে select:

// Blocking: চ্যানেলে জায়গা না থাকলে অপেক্ষা করে
results <- r

// Non-blocking: default থাকলে সাথে সাথে ফেরে
select {
case results <- r:
    // পাঠানো গেছে
default:
    log.Println("চ্যানেল ভর্তি, এটা বাদ দিলাম")
}

// মাঝামাঝি: টাইমআউট পর্যন্ত অপেক্ষা
select {
case resp := <-respCh:
    handle(resp)
case <-time.After(2 * time.Second):
    return errors.New("timeout")
}

মনে রাখো: Node.js বা Python asyncio-তে একটাও blocking কল পুরো event loop আটকে দেয়। Go-তে goroutine block হলে সমস্যা নেই, কিন্তু Go-র নিজের কমন বাগ হলো goroutine leak: একটা goroutine এমন চ্যানেলে চিরকাল আটকে আছে যেটা আর কেউ কখনো পড়বে না। প্রতিটা goroutine কীভাবে শেষ হবে তা আগে থেকে ঠিক করো, আর বাতিল করার জন্য context.Context ব্যবহার করো।

consumer যখন producer-এর চেয়ে ধীর, তখন সিস্টেমের এমন একটা উপায় লাগে যাতে কাজ ঢোকার গতি কমানো যায়।

ধরো প্রতি সেকেন্ডে ১০০০টা ইভেন্ট আসছে, কিন্তু তুমি প্রসেস করতে পারো ৮০০টা। প্রতি সেকেন্ডে ২০০টা জমছে। এক ঘণ্টায় ৭ লাখের বেশি। unbounded কিউ থাকলে মেমোরি ভরে সার্ভার মারা যাবে, আর মরার আগে প্রতিটা রিকোয়েস্টের latency বাড়তেই থাকবে।

মনে রাখো: unbounded কিউ মানে সমস্যাটাকে পরের জন্য রেখে দেওয়া, সমাধান নয়। প্রতিটা কিউর একটা সীমা আর সীমা পার হলে কী হবে তার একটা স্পষ্ট নীতি থাকা চাই।

যে ডেটা কেউ বদলাতে পারে না, সেটা সুরক্ষিত রাখা সবচেয়ে সহজ।

রেস কন্ডিশনের জন্য দুটো জিনিস লাগে: শেয়ার করা এবং বদলানো। একটা সরিয়ে দিলেই সমস্যা শেষ। Immutable অবজেক্ট তৈরির পর আর বদলায় না, তাই হাজারটা থ্রেড একসাথে পড়লেও কোনো লক লাগে না। "বদলাতে" চাইলে পুরনোটা রেখে নতুন একটা কপি বানাও।

type Config struct {
    timeout time.Duration   // ছোট হাতের নাম: প্যাকেজের বাইরে থেকে বদলানো যায় না
    retries int
}

func NewConfig(t time.Duration, r int) Config { return Config{timeout: t, retries: r} }

func (c Config) Retries() int { return c.retries }

// value receiver: c হলো একটা কপি, তাই আসলটা অপরিবর্তিত থাকে
func (c Config) WithRetries(r int) Config {
    c.retries = r
    return c
}

cfg := NewConfig(5*time.Second, 3)
newCfg := cfg.WithRetries(5)        // cfg.Retries() এখনো 3

Go-তে frozen বা final নেই, তাই immutability আসে নিয়ম মেনে: ফিল্ড unexported রাখো, শুধু পড়ার মেথড দাও, আর বদল মানে নতুন কপি ফেরত দেওয়া। সাবধান: struct কপি করলেও ভেতরের slice আর map আগের মেমোরিই দেখায়, সেগুলো আলাদা করে কপি করতে হয়।

মনে রাখো: কনফিগারেশন হট-রিলোড করার নিরাপদ উপায়: নতুন immutable config অবজেক্ট বানাও, তারপর একটা atomic রেফারেন্স একবারে নতুনটায় সরিয়ে দাও (Go-তে atomic.Pointer[Config]-এর Store(), আর পড়ার সময় Load())। কোনো থ্রেড কখনো অর্ধেক-আপডেট হওয়া config দেখবে না।

retry বা একই কাজ দুবার চললেও ফলাফল সঠিক থাকা চাই।

ডিস্ট্রিবিউটেড সিস্টেমে ডুপ্লিকেট এড়ানো যায় না। নেটওয়ার্ক টাইমআউট হলে ক্লায়েন্ট জানে না সার্ভারে কাজটা হয়েছে কিনা, তাই আবার পাঠায়। মেসেজ কিউ সাধারণত "at-least-once" গ্যারান্টি দেয়, মানে একই মেসেজ দুবার আসতে পারে। Idempotent অপারেশন একবার করা আর দশবার করার ফল একই।

SET status = 'paid' idempotent। balance = balance - 500 idempotent নয়, প্রতিবার আরো টাকা কাটবে।

সমাধান হলো idempotency key: ক্লায়েন্ট প্রতিটা অপারেশনের জন্য একটা ইউনিক আইডি পাঠায়। সার্ভার আগে দেখে এই আইডি দিয়ে কাজ হয়েছে কিনা।

কিন্তু এখানে লুকিয়ে আছে আরেকটা রেস কন্ডিশন। দুটো ডুপ্লিকেট রিকোয়েস্ট একই মিলিসেকেন্ডে এলে দুজনেই চেক করে "আগে হয়নি" দেখবে, দুজনেই টাকা কাটবে। তাই চেক আর লেখা atomic হতে হবে, আর সেটা করার কাজ ডেটাবেসের unique constraint-এর:

CREATE TABLE payments (
  idempotency_key TEXT PRIMARY KEY,
  amount          INTEGER NOT NULL,
  status          TEXT NOT NULL
);

-- দুটো রিকোয়েস্ট একসাথে এলেও শুধু একটা insert সফল হবে
INSERT INTO payments (idempotency_key, amount, status)
VALUES ('ord-8812-try', 500, 'processing')
ON CONFLICT (idempotency_key) DO NOTHING;
-- ০টা row insert হলে: এটা ডুপ্লিকেট, আগের ফলাফল ফেরত দাও

মনে রাখো: এটা পুরো গাইডের সারকথা। রেস কন্ডিশন (০৫) সমাধানে atomic অপারেশন (১৪) লাগে, আর সেটাই idempotency (২০)-কে নিরাপদ করে। কনকারেন্সির কনসেপ্টগুলো আলাদা নয়, একটা আরেকটার উপর দাঁড়িয়ে।