Skip to main content

Offline এ কিছু লিখলে অনলাইনে আসার পর অনলাইনে Data কীভাবে Sync হয়?

 যেমন গুগল Keep, Notion, কিংবা WhatsApp— আমরা অফলাইনে অনেক সময় অনেক কিছু লেখি,, সেগুলো আবার অনলাইনে আসতেই কীভাবে সার্ভারের সাথে মিলিয়ে ফেলে।


আসলে এর পেছনে কাজ করে Offline-First Architecture, Local Database, Sync Queue, এবং smart conflict resolution techniques।

প্রথমে ব্যবহারকারী যেকোনো কিছু লিখলে বা অ্যাকশন নিলে অ্যাপ সেটিকে সরাসরি লোকাল ডাটাবেজে সেভ করে। মোবাইল অ্যাপগুলো সাধারণত SQLite/CoreData, আর ওয়েব অ্যাপগুলো IndexedDB বা Cache Storage ব্যবহার করে। এতে ইন্টারনেট না থাকলেও ব্যবহারকারী কাজ চালিয়ে যেতে পারে।

অ্যাপ সবসময় ডিভাইসের নেটওয়ার্ক Status দেখে। অফলাইনে থাকলে সব পরিবর্তন Pending Sync Queue-তে জমা হয়। অনলাইনে ফিরলেই Background Sync চালু হয় একে একে সব pending changes সার্ভারে পাঠানো হয়।

 সার্ভার কোন অ্যাকশন গ্রহণ করলে তা লোকাল কিউ থেকে সরিয়ে ফেলা হয় এবং UI আপডেট হয়। WhatsApp-এর offline message sending বা Keep/Notion-এর offline note sync হওয়ার পেছনে এই প্রক্রিয়াই কাজ করে।

খুব গুরুত্বপূর্ণ একটি বিষয় হলো conflict resolution। দুই ডিভাইস বা দুই ব্যবহারকারী যদি একই ডাটা একসাথে পরিবর্তন করে, তখন অ্যাপকে কোন পরিবর্তন আগে নেবে তা সিদ্ধান্ত নিতে হয়। অনেক অ্যাপ timestamp ও version number দিয়ে smart merging করে।

Google Docs এর মতো collaborative অ্যাপ ব্যবহার করে Operational Transformation (OT), আর Notion বা Figma এর মতো modern collaborative system ব্যবহার করে CRDT (Conflict-free Replicated Data Types)। এগুলো real-time multi-user editing-এর backbone।

ডাটা সিঙ্ককে আরও কার্যকর করতে অনেক অ্যাপ পুরো ডাটা না পাঠিয়ে শুধু পরিবর্তনগুলো পাঠায়—এটাকে বলা হয় Delta Sync বা Incremental Sync। এতে bandwidth বাঁচে, performance বাড়ে।

আরেকটি গুরুত্বপূর্ণ অংশ হলো Optimistic UI। ব্যবহারকারী কোনো অ্যাকশন নেওয়ার সঙ্গে সঙ্গে UI-তে পরিবর্তন দেখায়, সার্ভারের approval-এর জন্য অপেক্ষা করে না। পরে যদি সার্ভার reject করে, তখন rollback হয়। WhatsApp-এ message টাইপ করার পর ✔→✔✔ আপডেট হওয়া এই প্যাটার্নেরই উদাহরণ।

নেটওয়ার্ক যদি unstable হয়, Sync request গুলো কয়েকবার retry করা হয়। তবে প্রতিবার একটু বেশি সময় অপেক্ষা করে—এটাকে বলা হয় Exponential Backoff—যাতে সার্ভার অতিরিক্ত লোডে পড়ে না।

সব মিলিয়ে, পুরো সিস্টেমটি এমনভাবে তৈরি হয় যেন ব্যবহারকারীর অভিজ্ঞতা কখনো থেমে না যায়। ব্যবহারকারী offline হোক বা online—data আগে লোকালি সেভ হয়, পরে server-এর সাথে sync হয়।

Comments

Post a Comment

Popular posts from this blog

Django pk vs id

 Django pk VS id If you don’t specify primary_key=True for any fields in your model, Django will automatically add an IntegerField to hold the primary key, so you don’t need to set primary_key=True on any of your fields unless you want to override the default primary-key behavior. The primary key field is read-only. If you change the value of the primary key on an existing object and then save it, a new object will be created alongside the old one Example: class UserProfile ( models . Model ): name = models . CharField ( max_length = 500 ) email = models . EmailField ( primary_key = True ) def __str__ ( self ): return self . name suppose we have this model. In this model we have make email field as primary key. now django default primary key id field will be gone. It'll remove from database. we can not query as   UserProfile.objects.get(id=1) after make email as primary key this query will throw an error.  Now we have to use pk  Us...
Post a Comment
Read more

WSGI vs ASGI: What Every Django Developer Should Know !

  If you've been developing with Django, you've probably come across WSGI (Web Server Gateway Interface), the trusted friend of all traditional, synchronous web apps. But in this fast-moving, real-time world, you may have also heard about its dynamic, asynchronous cousin ASGI (Asynchronous Server Gateway Interface). WSGI (Web Server Gateway Interface): 1. The OG (original) Django interface, designed for synchronous HTTP requests. 2. Perfect for blogs, CMS, e-commerce, and standard web apps. 3. Uses servers like Gunicorn or uWSGI. 4. Limited to handling one request at a time. ASGI (Asynchronous Server Gateway Interface): 1. The modern, scalable interface designed for asynchronous web apps. 2. Ideal for handling WebSockets, HTTP/2, and real-time features like chat apps. 3. Built for high concurrency; uses Uvicorn, Daphne, or similar ASGI servers. 4. Allows you to leverage Python’s async and await for non-blocking code. When to Choose What: WSGI: Traditional apps where synchronou...
Post a Comment
Read more

Sum of numbers 1 to N

 Problem: We need the sum of the number 1 to N. The N could be anything (100,200,500,33,21) like anything. What is the best approach to solve this little problem ?  so there are multiple way to solve this problem.  We will discuss 3 solution .  1. Recursive way  : Using recursion we can solve this problem. Here is the solution The time complexity of this code is O(n) because it makes n recursive calls, each of which takes constant time.  The space complexity is also O(n) because each recursive call adds a level to the call stack. The maximum depth of the recursion is n, so the maximum amount of space on the call stack is proportional to n. 2. Using loop Here we need 2 different variables in our code -- a variable where we can store the sum as we iterate through the values and add them (my_sum in my code), and another variable (i in my code) to iterate over the numbers from 0 to n. The time complexity of this code is O(n). The while loop runs n+1 times, and ...
Post a Comment
Read more