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

Implementing Advance Query Optimization in Django ORM

 Django's ORM makes database interactions seamless, allowing developers to write queries in Python without raw SQL. However, as applications scale, inefficient queries can slow down performance, leading to high latency and database load.  This guide explores advanced query optimization techniques in Django ORM to go beyond basic CRUD (Create, Read, Update, Delete) operations and improve efficiency.  1. Use QuerySet Caching to Avoid Repeated Queries Using cache reduces redundant queries for frequently accessed data. Caching helps reduce repeated database hits. 2. Avoid .count() on Large Datasets Using .count() on large tables can be expensive Inefficient way: Optimized way ( .exists() is Faster) 3. Use Indexes for Faster Lookups Indexes speed up queries on frequently filtered fields. Add db_index=True for frequently queried fields: 4. Optimize Bulk Inserts and Updated Performing operations on multiple records one by one is inefficient. Use bulk_create() for mass insert...
Post a Comment
Read more

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

Django select_related and prefetch_related

  Difference between select_related and prefetch_related Reducing SQL queries is one of the first steps when optimizing a Django project. There are two powerful methods included in the Django ORM to help us that can boost performance by creating a single more complex QuerySet rather than multiple, smaller queries. In this project we will understand about  select_related and prefetch_related.  Django use these two orm method to reduce sql queries in database based on different scenario.  select_related Lets assume  this two model we have.  class Author ( models . Model ): name = models . CharField ( max_length = 200 ) def __str__ ( self ): return self . name class Courses ( models . Model ): name = models . CharField ( max_length = 200 ) author = models . ForeignKey ( Author , on_delete = models . CASCADE , related_name = 'courses' ) def __str__ ( self ): return self . name Here we have two mode. ...
Post a Comment
Read more