Offline Queue: নীতি, কৌশল এবং কাজের পদ্ধতি

অফলাইন কিউ কী?

Offline Queue হল অপারেশনগুলির (তৈরি, আপডেট, মুছে ফেলা) একটি ক্রমবিন্যস্ত সংগ্রহ যা অ্যাপ্লিকেশন স্থানীয়ভাবে সংরক্ষণ করে যখন ডিভাইসের নেটওয়ার্ক অ্যাক্সেস নেই। সংযোগ পুনরুদ্ধার করা হলে, কিউ ব্যবহারকারী যে ক্রমে কাজগুলি সম্পাদন করেছেন সেই একই ক্রমে সার্ভারে অপারেশন পাঠায়।

একটি দৃশ্যকল্প কল্পনা করুন: একজন মেসেঞ্জার ব্যবহারকারী ইন্টারনেট ছাড়া মেট্রোতে বার্তা টাইপ করছেন। «পাঠান»-এর প্রতিটি ট্যাপ Offline Queue-তে যোগ হয়। যখন ট্রেন টানেল থেকে বেরিয়ে আসে এবং নেটওয়ার্ক উপলব্ধ হয়, সমস্ত বার্তা স্বয়ংক্রিয়ভাবে পাঠানো হয়। ব্যবহারকারীর অভিজ্ঞতা — নির্বিঘ্ন: তারা লক্ষ্য করে না যে তারা অফলাইনে ছিল, পাঠাতে সামান্য বিলম্ব ছাড়া।

Uber Engineering (2024) অনুসারে, তাদের অফলাইন কিউ খারাপ সংযোগযুক্ত অঞ্চলে প্রতিদিন ২ মিলিয়নেরও বেশি অপারেশন প্রক্রিয়া করে। কিউ FIFO ক্রম এবং exactly-once গ্যারান্টিযুক্ত বিতরণ প্রক্রিয়া সহ Room স্থানীয় স্টোরেজ ব্যবহার করে।

data class QueuedOperation(
    val id: String,
    val type: OperationType,
    val endpoint: String,
    val payload: String,
    val timestamp: Long,
    val retryCount: Int = 0,
    val idempotencyKey: String
)

প্রতিটি অপারেশনে পুনঃপ্রেরণের জন্য প্রয়োজনীয় সমস্ত ডেটা থাকে: এন্ডপয়েন্ট, অনুরোধের বডি, টাইমস্ট্যাম্প এবং idempotencyKey। Room ডাটাবেস অ্যাপ্লিকেশন পুনরায় চালু এবং OS ক্র্যাশের সময় কিউ-এর স্থায়িত্ব নিশ্চিত করে।

মোবাইল অ্যাপে অপারেশন কিউ কেন প্রয়োজন

ডেলিভারি গ্যারান্টি — কিউ-এর মূল উদ্দেশ্য। ব্যবহারকারীর আস্থা থাকা উচিত যে তাদের কাজ (বার্তা পাঠানো, লাইক দেওয়া, অর্ডার করা) সম্পন্ন হবে, এমনকি যদি সেই মুহূর্তে নেটওয়ার্ক অনুপলব্ধ থাকে। রিট্রাই প্রক্রিয়া সহ Offline Queue শেষ পর্যন্ত ডেলিভারি নিশ্চিত করে।

দুর্বল সংযোগ পরিস্থিতিতে উন্নত UX — GSMA Mobile Economy Report (2025) অনুসারে, বিশ্বব্যাপী প্রায় ৪০% মোবাইল ব্যবহারকারীর অস্থির ইন্টারনেট সংযোগ রয়েছে। Offline Queue অ্যাপ্লিকেশনটিকে মেট্রো, লিফট, দূরবর্তী এলাকায় ব্যবহারযোগ্য করে তোলে — যেখানেই সংযোগ বিচ্ছিন্ন থাকে।

তথ্য ক্ষতি হ্রাস — কিউ ছাড়া, অফলাইনে সম্পাদিত সমস্ত কাজ হারিয়ে যায়। একজন ব্যবহারকারী একটি দীর্ঘ ফর্ম পূরণ করতে পারেন, «জমা দিন»-এ ট্যাপ করতে পারেন এবং একটি নেটওয়ার্ক ত্রুটি দেখতে পারেন — সমস্ত ইনপুট হারিয়ে যায়। Offline Queue ডেটা সংরক্ষণ করে এবং প্রথম সুযোগে পাঠায়। Google Docs-এ অটো-সেভ নথির জন্য অফলাইন কিউ-এর একটি ক্লাসিক উদাহরণ।

অ্যাসিনক্রোনাস সিঙ্ক্রোনাইজেশন — কিউ অ্যাপ্লিকেশনকে পাঠানোর সময় UI ব্লক করতে দেয় না। ব্যবহারকারী কাজ চালিয়ে যান যখন সিঙ্ক ম্যানেজার ব্যাকগ্রাউন্ডে কিউ প্রক্রিয়া করে। এটি রিঅ্যাকটিভ আর্কিটেকচার নীতি অনুসরণ করে এবং ইন্টারফেসের প্রতিক্রিয়াশীলতা উন্নত করে।

অফলাইন কিউ আর্কিটেকচার: স্টোরেজ এবং প্রক্রিয়াকরণ

কিউ-এর তিনটি স্তর: স্টোরেজ (স্থায়িত্ব), শিডিউলার (scheduler) এবং এক্সিকিউটর (executor)। স্টোরেজ — QueuedOperation টেবিল সহ Room। শিডিউলার — WorkManager (Android) বা BGTaskScheduler (iOS) যা নেটওয়ার্ক উপলব্ধ হলে সিঙ্ক্রোনাইজেশন শুরু করে। এক্সিকিউটর — একটি অনুক্রমিক FIFO পুনরাবৃত্তিকারী যা একে একে অপারেশন পাঠায়।

প্রক্রিয়াকরণের ক্রম — ডেটা ধারাবাহিকতার জন্য গুরুত্বপূর্ণ। যদি কোনও ব্যবহারকারী একটি রেকর্ড তৈরি করে এবং তারপর এটি সম্পাদনা করে, তবে উভয় অপারেশন একই ক্রমে পাঠানো আবশ্যক। অন্যথায়, সার্ভার প্রথমে একটি অস্তিত্বহীন রেকর্ডের আপডেট পায় — ত্রুটি। অনুক্রমিক FIFO — অপারেশনগুলির মধ্যে নির্ভরতা নিয়ন্ত্রণ সহ কঠোর ক্রম।

একত্রীকরণ কৌশল — যদি কিউ-তে একটি CREATE এবং সাথে সাথে একই অবজেক্টের DELETE থাকে, তবে উভয় অপারেশন না পাঠিয়েই মুছে ফেলা যেতে পারে: চূড়ান্ত অবস্থা হল যে অবজেক্টটি তৈরি করা হয়নি। একইভাবে, CREATE + UPDATE সর্বশেষ ডেটা সহ একটি CREATE-তে একত্রিত করা যেতে পারে। কিউ অপ্টিমাইজেশন HTTP অনুরোধের সংখ্যা হ্রাস করে এবং সিঙ্ক্রোনাইজেশন দ্রুত করে।

Android Developers (2025) অনুসারে, Android-এ Offline Queue পরিচালনার পছন্দের উপায় হল WorkManager: এটি ডিভাইস পুনরায় চালু হওয়ার পরেও এক্সিকিউশনের গ্যারান্টি দেয়, নেটওয়ার্ক সীমাবদ্ধতা সমর্থন করে এবং NetworkType.CONNECTED-এর মাধ্যমে রিট্রাই নীতি কনফিগার করার অনুমতি দেয়।

class SyncWorker(
    private val context: Context,
    private val params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = runCatching {
        queueRepository.processNextBatch(batchSize = 10)
        Result.success()
    }.getOrDefault(Result.retry())
}

CoroutineWorker অপারেশন ব্যাচ প্রক্রিয়া করে এবং ব্যর্থ হলে Result.retry() ফেরত দেয় — WorkManager এক্সপোনেনশিয়াল ব্যাকঅফের সাথে স্বয়ংক্রিয়ভাবে পুনরায় চেষ্টা করে। Android-এ নির্ভরযোগ্য Offline Queue পাওয়ার এটি সবচেয়ে সহজ উপায়।

পুনরায় চেষ্টার কৌশল: exponential backoff এবং রিট্রাই নীতি

Exponential Backoff — বর্ধিত ব্যবধান সহ একটি মানক পুনরায় চেষ্টার কৌশল: ২ সেকেন্ড, ৪ সেকেন্ড, ৮ সেকেন্ড, ১৬ সেকেন্ড এবং আরও অনেক কিছু সর্বোচ্চ সীমা পর্যন্ত। এটি অস্থায়ীভাবে অনুপলব্ধ হলে সার্ভারের বারবার ওভারলোড প্রতিরোধ করে। Java লাইব্রেরি Resilience4j (2024) কনফিগারযোগ্য ব্যাকঅফ সহ একটি প্রস্তুত Retry বাস্তবায়ন প্রদান করে।

সর্বাধিক প্রচেষ্টা গণনা — একটি গুরুত্বপূর্ণ প্যারামিটার। যদি ৫–১০টি প্রচেষ্টার পরেও অপারেশন ব্যর্থ হয়, তবে আরও প্রচেষ্টা অপচয় এবং অকেজো। একটি dead letter queue সুপারিশ করা হয়: প্রচেষ্টা শেষ হওয়ার পরে, অপারেশন ম্যানুয়াল বিশ্লেষণের জন্য একটি পৃথক টেবিলে সরানো হয়। Microsoft Patterns & Practices (2024) অনুসারে, dead letter queue সিঙ্ক্রোনাইজেশন সমস্যা ডিবাগ করা সহজ করে এবং ত্রুটিপূর্ণ অপারেশনগুলিকে কিউ ব্লক করা থেকে বিরত রাখে।

Jitter — এলোমেলো বৈচিত্র্য — ব্যাকঅফ ব্যবধানে একটি এলোমেলো সংখ্যা যোগ করা। যদি এক হাজার ডিভাইস একই সাথে বিভ্রাটের পরে নেটওয়ার্ক পুনরুদ্ধার করে, তারা সবাই একই সময়ে সিঙ্ক করা শুরু করে। Jitter তাদের সময় জুড়ে ছড়িয়ে দেয়, সার্ভারে Cache Stampede প্রতিরোধ করে। সম্পূর্ণ jitter: delay = random(0, backoff) — API ক্লায়েন্টদের জন্য AWS (2024) দ্বারা সুপারিশকৃত।

সংঘাত নিরসন: ডেটা বিরোধ কীভাবে সমাধান করবেন

Last Write Wins (LWW) — সবচেয়ে সহজ কৌশল: বিরোধের ক্ষেত্রে, পরবর্তী টাইমস্ট্যাম্পের অপারেশন জয়ী হয়। LWW-তে সময় সিঙ্ক্রোনাইজেশন প্রয়োজন — টাইমস্ট্যাম্প সার্ভারে উত্পন্ন হতে হবে বা লজিক্যাল ক্লক (ল্যাম্পোর্ট ক্লক) ব্যবহার করতে হবে। অসুবিধা: একজন ব্যবহারকারীর ডেটা সতর্কতা ছাড়াই অন্য ব্যবহারকারীর ডেটা দ্বারা ওভাররাইট করা যেতে পারে।

OT (অপারেশনাল ট্রান্সফর্মেশন) — Google Docs এবং Figma দ্বারা রিয়েল-টাইম সহযোগিতামূলক সম্পাদনার জন্য ব্যবহৃত অ্যালগরিদম, অফলাইন মোড সহ। OT অপারেশনগুলিকে রূপান্তরিত করে যাতে সেগুলি ডকুমেন্টের যেকোনো অবস্থায় প্রয়োগ করা যায়, লক ছাড়াই ধারাবাহিকতা নিশ্চিত করে। CRDT (কনফ্লিক্ট-ফ্রি রিপ্লিকেটেড ডেটা টাইপস) — OT-এর একটি বিকল্প যা মোবাইল অ্যাপে জনপ্রিয়তা অর্জন করছে: ডেটা এমনভাবে গঠন করা হয় যে কেন্দ্রীয় সার্ভার ছাড়াই গাণিতিকভাবে বিরোধ সমাধানযোগ্য।

কাস্টম মার্জ — সহজ ডেটা মডেল (নোট, পরিচিতি) সহ অ্যাপের জন্য, কাস্টম মার্জ নিয়ম প্রয়োগ করা যেতে পারে। উদাহরণস্বরূপ, একটি নোটের জন্য: যদি দুটি সংস্করণে পাঠ্য সংশোধিত হয়, তবে একটি বিভাজক সহ সংযুক্তি হিসেবে মার্জ করুন। ব্যবহারকারী-সমাধানিত বিরোধ — যদি স্বয়ংক্রিয় মার্জ অসম্ভব হয়, ব্যবহারকারীকে উভয় সংস্করণ দেখান এবং বেছে নিতে দিন। Dropbox (2024) অফলাইন ফাইল বিরোধের জন্য এই পদ্ধতি ব্যবহার করে, «Conflicted Copy» উপসর্গ সহ কপি তৈরি করে।

Idempotency keys — ডুপ্লিকেশন থেকে সুরক্ষা

Idempotency Key — একটি অনন্য অপারেশন সনাক্তকারী যা সার্ভার ডুপ্লিকেট অনুরোধ সনাক্ত করতে ব্যবহার করে। যদি ক্লায়েন্ট একই কী সহ একই অনুরোধ পাঠায়, সার্ভার পুনরায় এক্সিকিউট না করেই ইতিমধ্যে সম্পন্ন অপারেশনের ফলাফল ফেরত দেয়। এটি Offline Queue-এর জন্য অত্যন্ত গুরুত্বপূর্ণ, যেখানে নেটওয়ার্ক ত্রুটির কারণে পুনঃপ্রেরণ সম্ভব।

Idempotency key-এর বিন্যাস হল UUID বা অনুরোধের প্যারামিটারের হ্যাশ। সার্ভারকে ডুপ্লিকেট সনাক্ত করতে কিছু সময়ের জন্য (সাধারণত ২৪ ঘন্টা) ফলাফল সহ সম্পূর্ণ কী সংরক্ষণ করতে হবে। Stripe API (2024) রেফারেন্স উদাহরণ: কী Idempotency-Key হেডারে পাঠানো হয়, এবং একই কী সহ পুনরাবৃত্ত অনুরোধগুলি ক্যাশড প্রতিক্রিয়া ফেরত দেয়।

ক্লায়েন্ট-সাইড জেনারেশন — অপারেশন পাঠানোর আগে ক্লায়েন্টে কী তৈরি করা হয় এবং QueuedOperation টেবিলে সংরক্ষণ করা হয়। পুনরায় চেষ্টা করার সময়, কী পরিবর্তন হয় না। Exactly-once আর্কিটেকচার — ক্লায়েন্টে idempotency key এবং সার্ভারে ডিডুপ্লিকেশনের সংমিশ্রণ হল গ্যারান্টি দেওয়ার একমাত্র উপায় যে একটি অপারেশন দুবার এক্সিকিউট করা হবে না।

fun createOperation(type: OperationType, payload: String): QueuedOperation =
    QueuedOperation(
        id = UUID.randomUUID().toString(),
        type = type,
        endpoint = type.endpoint,
        payload = payload,
        timestamp = currentTimeMillis(),
        idempotencyKey = UUID.randomUUID().toString()
    )

প্রতিটি অপারেশন দুটি UUID পায়: একটি — কিউ-তে রেকর্ড সনাক্তকারী, দ্বিতীয় — সার্ভারের জন্য idempotency key। idempotencyKey দ্বারা সার্ভার-সাইড ডিডুপ্লিকেশন গ্যারান্টি দেয় যে পুনঃপ্রেরণেও, অর্ডারটি ডুপ্লিকেট হবে না।