Coder Legion - Recent posts tagged read

How Do Smart Devices Perform Multiple Tasks?

Mon, 04 May 2026 10:58:23 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

Ever wonder how your Alexa, robot vacuum cleaner, and smartwatch seamlessly perform multiple tasks without getting stuck in the middle? How exactly are these devices programmed to handle it all?

You came to the right place to understand how it happens under the hood.

In this article, we will understand how these tasks are performed and how they work.

As all these devices use a microcontroller. I will be explaining using the simple microcontroller ESP8266.

How will the task be performed?

Every smart device consists of a microcontroller. These microcontrollers are programmed to perform specific tasks.

These tasks are performed using a single loop function.

void loop() {
 // Perform Task
}

This loop function will run continuously.

In this loop, we can do multiple things.

Let's take the example of a weather monitoring device.
These operations are done using a single loop function. As there is nothing else to do.

Start Device
Start Loop
Read sensor data
Display data / Store data
Repeat the process

void loop() {
 // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

 // Send data to cloud
  sendDataToCloud(temperature, humidity);
}

But this comes with a problem.

This loop will be running with a microsecond delay.
If we run this loop function, it will run continuously. Means there will be no delay between the operations.

How will a normal loop cause a problem?

Let's assume the above operation takes 1 ms (which is not true in real-world use, as it depends on which microcontroller you use).

The DHT11 sensor should have a 1-second delay between readings.

That means the above loop will run 1000 times in 1 second to just see if the sensor data has changed.

Can you see the problem?

1000 times operation means 1000 times power consumption.

1000 times the power consumption means the battery will drain fast, or the embedded system will heat up.

To avoid this, we can use a delay function.

void loop() {
 // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

 // Send data to cloud
  sendDataToCloud(temperature, humidity);

 // Wait for 1 second
  delay(1000);
}

By adding a delay, we are making sure that the loop function is not running continuously.

This is a good implementation if we have only one task to perform.

But if we want to do multiple operations to be performed in specific intervals.

Adding Other Operations in a loop

Like this, if we want to read the DHT11 sensor every 1 second and read the MQ2 sensor every 5 seconds. We can't use the delay function.

It will be like this.

void loop() {
 // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

 // Send data to cloud
  sendDataToCloud(temperature, humidity);
 // Read data from sensor
  float gas = analogRead(MQ2_PIN);

 // Send data to cloud
  sendDataToCloud(gas);

 // Wait for 5 seconds
  delay(5000);
}

This will cause a 5-second no-data reading from the DHT11 sensor.

Hence, there will be data loss for 5 seconds.

Here is where the task scheduler comes into the picture.

What is Task Scheduler?

A task scheduler is a lightweight system that allows a processor to juggle multiple activities seemingly at the same time, a concept known as multitasking.

A Task Scheduler solves this problem using a "to-do list" approach.

Instead of freezing, the program loops continuously at top speed.

Every time it loops, the scheduler checks the clock and looks at its list of tasks to see if any are due to run right now.

If a task's time is up, the scheduler runs it and then immediately goes back to checking the clock.

To understand the internal clock, imagine the microcontroller holding a stopwatch that starts counting milliseconds the moment it powers on.

In the Arduino framework, this stopwatch is read using a function called millis().

Instead of pausing the whole system to wait, the scheduler constantly checks this stopwatch against a simple formula for each task:

Current Time - Last Time Executed >= Interval

Here is a simple example of how the task scheduler works in ESP8266.

Ex:

unsigned long previousDHTTime = 0; // Remembers the last time DHT ran
unsigned long previousMQ2Time = 0; // Remembers the last time MQ2 ran

const long dhtInterval = 1000; // 1000 milliseconds = 1 second
const long mq2Interval = 5000; // 5000 milliseconds = 5 seconds

void setup() {
 // Initialization code goes here
}

void loop() {
 // 1. Read the internal stopwatch
  unsigned long currentMillis = millis(); 

 // 2. Check the DHT Task
  if (currentMillis - previousDHTTime >= dhtInterval) {
 previousDHTTime = currentMillis; // Reset this task's timer
    float temperature = dht.readTemperature();
    float humidity = dht.readHumidity();

 // Send data to cloud
    sendDataToCloud(temperature, humidity);

 }

 // 3. Check the MQ2 Task
  if (currentMillis - previousMQ2Time >= mq2Interval) {
 previousMQ2Time = currentMillis; // Reset this task's timer

    float gas = analogRead(MQ2_PIN);

 // Send data to cloud
    sendDataToCloud(gas);
 }
}

This way, we can perform multiple operations in specific intervals without blocking the loop function.

Core Logic of Task Scheduler

I want to perform two operations in ESP8266.

Blink the LED every 2.5 seconds 1 time.
Blink the LED every 5 seconds 2 times.

Let's see how to do this without using the built-in task scheduler.

Set up serial communication and the LED pin.
Start Loop.
Check if 2.5 seconds have passed since the last task activation.
If yes, perform the blink.
Check if 5 seconds have passed since the last task activation.
If yes, perform the blink

#include <Arduino.h>

unsigned long t25, t50;

/**
 * Performs a single blink on the built-in LED (Active Low).
 * @param message Debug message to output to Serial.
 */
void performBlink(const char *message) {
  Serial.println(message);
  digitalWrite(LED_BUILTIN, 0); // LED ON
  delay(80);
  digitalWrite(LED_BUILTIN, 1); // LED OFF
  delay(80);
}

void setup() {
  Serial.begin(115200);
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, 1); // Start with LED OFF
}

void loop() {
 // Task 1: Every 2.5s (triggers at 2.5s, 5.0s, 7.5s...)
  if (millis() - t25 >= 2500) {
 t25 = millis();
    performBlink("[2.5s] ");
 }

 // Task 2: Every 5.0s (triggers at 5.0s, 10.0s...)
 // At 5s, both tasks trigger, resulting in a double blink.
  if (millis() - t50 >= 5000) {
 t50 = millis();
    performBlink("[5.0s] ");
 }
}

Output:

[2.5s] 
[5.0s] 
[2.5s] 
[2.5s] 
[5.0s]

See, as we defined, to use a 2.5 sec interval for the first task and a 5 sec interval for the second task.

This also means the 2nd time, a 2.5 sec blink will happen after 5 sec from the 1st blink.

This will create a 2-second blink in 5 sec.

<h2

Five Caching Strategies Every Backend Dev Should Know

Sun, 19 Apr 2026 19:33:53 +0000

Five Caching Strategies Every Backend Dev Should Know

If you build backend systems, you eventually run into caching.

Someone says “just put Redis in front of it” and suddenly your app is faster… until you start seeing stale data, cache misses, and weird bugs when you deploy.

This post explains five core caching strategies in plain language:

Cache-Aside
Read-Through
Write-Through
Write-Back
Write-Around

You’ll see how each one works, what can go wrong, and when to use it.

A cache is just a faster, smaller copy of some data. The hard part is keeping that copy useful: when to fill it, when to read from it, and when to update or skip it.

1. Cache-Aside (Lazy Loading)

Idea: The application talks to the cache and the database. It “checks the cache first, then falls back to the DB” and fills the cache on a miss.

If the key is in the cache (a hit), just return it. Super fast.


If the key is missing, the app queries the database instead.


The app stores the result in the cache and returns it to the user.

Why people love it

Simple and flexible: logic lives in your code; you control what goes in the cache.
Resilient: if the cache dies, the app can still read from the DB (just slower).
Memory-efficient: only data that is actually read gets cached.

What can go wrong

The first request for a key is slow (cold cache).
If the DB is updated outside your code path (e.g. admin tool, another service), the cache can serve stale data until TTL expires or you manually invalidate.

When to use

Great default for read-heavy apps (blogs, product catalogs, many dashboards).
When you’re just adding caching to an existing codebase and want full control.

2. Read-Through

Idea: The application pretends the cache is the main database.

It calls the cache for every read. On a miss, the cache layer itself fetches from the DB, stores the result, and returns it.

With Cache-Aside, your app code calls both cache and DB. With Read-Through, your app only calls the cache; a loader behind the cache talks to the DB.

Pros

Cleaner application code: your code only knows “get from cache”.
Cache libraries or infrastructure can handle loading, retries, and metrics.

Cons

If some writes go directly to the DB (bypassing the cache API), the cache can easily become stale.
You need a cache provider or library that supports read-through loading.

When to use

Larger teams where you want centralized cache logic, not ad-hoc caching scattered everywhere.
Situations where infra/platform team owns the cache layer.

3. Write-Through

So far we talked about reads. Now let’s talk about writes: how we keep cache and DB in sync.

Write-Through means:

On a write, update the cache and the database synchronously. Only when both succeed is the write considered “done”.

Flow

User updates something (e.g. changes quantity in a cart).
App writes the new value into the cache.
App also writes the same value into the database.
Only if both succeed do we return “OK” to the user.

Pros

Strong consistency: cache and DB always match for that key.
Reads from the cache always see the latest value.

Cons

Slower writes: every write has to hit both cache and DB before returning.
If DB is slow, your API write latency is also slow.

When to use

When correctness matters more than raw speed:
- balances in a wallet / bank,
- inventory in an e‑commerce site,
- data where a stale read would be really bad.

4. Write-Back (Write-Behind)

Write-Back trades strict consistency for speed.

On a write, update only the cache and return success quickly. Later, an async process flushes those changes to the database.

Flow

User sends a write.
App writes to cache and returns 200 OK immediately.
A background worker or the cache itself periodically writes batched updates into the DB.

Pros

Very fast writes: app isn’t blocked waiting for DB.
Great for high-throughput workloads:
- counters (views, likes),
- logs / telemetry,
- social feed events.

Cons

Risk of data loss: if the cache crashes before flushing to DB, those changes are gone.
DB is eventually updated, not immediately.

When to use

Write-heavy workloads where losing a tiny fraction of data is acceptable:
- metrics, dashboards, click-streams,
- non-critical logs.

5. Write-Around

Write-Around takes a different approach:

Writes skip the cache and go straight to the DB. The cache is only filled later when data is read.

Flow

A write goes directly into the database.
The cache is not updated.
On the next read, the app (or cache) sees a miss:
- loads from DB,
- populates the cache,
- and returns the value.

Pros

Prevents “polluting” the cache with data that is written but rarely read.
Good when you have big write batches (imports, ETL jobs) that users won’t read immediately.

Cons

The first read after a write is always a cache miss (slower).
More frequent DB reads if many keys are only read once.

When to use

Large imports, archival data, logs that might be read only occasionally.
Systems where memory is tight and you want the cache to focus on truly hot data.

Side-by-side comparison

Here’s a quick comparison of these five strategies using the labels you provided.

How teams typically choose

To connect this with the interactive content you built:

These charts show two things:

Cache-Aside dominates in real systems because it’s simple and resilient.
Write-Back gives the fastest writes but carries the most risk; Write-Through is safest but slower on each write.

Which caching strategy should you pick? (a practical rule-set)

If you only remember one thing from this post, remember this: you pick a caching strategy based on the cost of a stale read and the cost of a slow write.

Here’s a fast, real-world decision guide:

Most read-heavy apps (catalogs, blogs, dashboards):
- Start with Cache-Aside.
- Add TTLs and a plan for invalidation if data changes.
You want a clean abstraction and centralized caching (platform/infra owned):
- Use Read-Through so product code only depends on the cache API.
A stale read would be painful (wallet balances, inventory, “did my payment go through?”):
- Prefer Write-Through (consistency > speed).
Writes are hot and you can tolerate some eventual consistency (counters, analytics, clickstream):
- Consider Write-Back, but only with durability guardrails (below).
You write lots of data that is rarely read (imports, ETL, logs):
- Use Write-Around to avoid polluting the cache.

Two failure modes teams hit in production (and what to do)

Caching rarely fails in obvious ways. It fails with “the DB is melting” or “why is data stale?”. Two patterns show up everywhere.

1) Cache stampede (thundering herd)

Symptom: a hot key expires (or cache restarts), and suddenly thousands of requests miss at once and slam the DB.

Mitigations:

Request coalescing / single-flight: only one request recomputes the value; others wait and reuse it.
Stale-while-revalidate: keep serving a slightly stale value while one background refresh updates it.
Jittered TTLs: add randomization to expiration times so many keys don’t expire at the same second.

2) Hot key / hotspotting

Symptom: one key becomes so popular (home feed, trending item, auth config) that a single cache shard or a single DB row gets hammered.

Mitigations:

Shard the key (e.g. trending:v1:0..N) and merge results.
Use a two-layer cache: per-instance in-memory (tiny TTL) + shared Redis.
Precompute or cache at a higher level (edge/CDN) if the data is public.

What to monitor so caching doesn’t become “magic”

Whatever strategy you choose, watch these:

Cache hit rate (overall and by endpoint)
DB QPS (does caching actually reduce it?)
p95/p99 latency (cache helps only if tail latency improves)
Eviction rate / memory pressure (are you constantly evicting hot data?)
Stale reads / correctness signals (app-specific: inventory mismatches, stale dashboards, etc.)

If you can’t measure these, caching will eventually surprise you.

Putting it all together (for a newbie)

If you’re just starting with caching:

Start with Cache-Aside for reads. It’s simple, safe, and easy to reason about.
Add Read-Through if you want a cleaner abstraction and your cache provider supports it.
For writes:
- Use Write-Through when you absolutely need the cache and DB to agree on every write.
- Use Write-Back when you care a lot about write speed and can tolerate a little risk.
- Use Write-Around when you write lots of data that users won’t read immediately.
Whatever you choose, always:
- Set reasonable TTLs,
- Have a plan for invalidating keys,
- And monitor hit rate and latency so you can adjust over time.

With just these five strategies, you can handle most caching problems you’ll run into as a backend engineer.

How to perform multiple operations in the ESP8266?

Fri, 10 Apr 2026 21:18:16 +0000

In this article, We will be exploring how to perform multiple operations in ESP8266.

As we are using ESP8266, we will be using Arduino framework.
Let see how operations are performed in ESP8266 or any other embedded system.

How Operations are performed in ESP8266?

Before going to understand how to perform multiple operations in ESP8266. Let's understand what is how regular programming works in embedded systems.

Any activity in embedded system is done using loop function.

void loop() {
  // Do something
}

This loop function will run continuously.

In this loop we can do multiple things.

For example we can read dht11 sensor data

void loop() {
  // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

  // Send data to cloud
  sendDataToCloud(temperature, humidity);
}

But this comes with a problem.

If we run this loop function, it will run continuously. Means there will be no delay between the operations.

How Normal Loop will cause problem?

Let's assume above operation takes 1 ms (which is not true in real world).
And DHT11 sensor should have 1 second delay between readings.

That means above loop will run 1000 times in 1 second to just see if the sensor data is changed.

Can you see the problem?

1000 times operation means 1000 times power consumption.

1000 times power consumption means battery will drain fast or embedded system will heat up.

To Avoid this we can use delay function.

void loop() {
  // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

  // Send data to cloud
  sendDataToCloud(temperature, humidity);

  // Wait for 1 second
  delay(1000);
}

By adding delay we are making sure that the loop function is not running continuously.

But this also has a problem.

If we add delay of 1 second, it means the loop function will run only once in 1 second.

So if we want to do multiple operations to be performed in specific intervals. It will be blocked.

Adding Other Operation in loop

Like this if we want to read dht11 sensor every 1 second and read mq2 sensor every 5 seconds. We can't use delay function.

It will be like this

void loop() {
  // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

  // Send data to cloud
  sendDataToCloud(temperature, humidity);
  // Read data from sensor
  float gas = analogRead(MQ2_PIN);

  // Send data to cloud
  sendDataToCloud(gas);

  // Wait for 5 seconds
  delay(5000);
}

This will cause 5 sec no data reading from dht11 sensor.

Here where task scheduler comes into picture.

What is Task Scheduler?

A task scheduler is a lightweight system that allows a processor to juggle multiple activities seemingly at the same time, a concept known as multitasking.

A Task Scheduler solves this problem using a "to-do list" approach.

Instead of freezing, the program loops continuously at top speed.

Every time it loops, the scheduler checks the clock and looks at its list of tasks to see if any are due to run right now.

If a task's time is up, the scheduler runs it, and then immediately goes back to checking the clock.

To understand the internal clock, imagine the microcontroller holding a stopwatch that starts counting milliseconds the moment it powers on.

In Arduino framework, this stopwatch is read using a function called millis().

Instead of pausing the whole system to wait, the scheduler constantly checks this stopwatch against a simple formula for each task:

Current Time - Last Time Executed >= Interval

Here is simple example of how task scheduler works in ESP8266.

Ex:

unsigned long previousDHTTime = 0;  // Remembers the last time DHT ran
unsigned long previousMQ2Time = 0;  // Remembers the last time MQ2 ran

const long dhtInterval = 1000;      // 1000 milliseconds = 1 second
const long mq2Interval = 5000;      // 5000 milliseconds = 5 seconds

void setup() {
  // Initialization code goes here
}

void loop() {
  // 1. Read the internal stopwatch
  unsigned long currentMillis = millis(); 

  // 2. Check the DHT Task ⏱️
  if (currentMillis - previousDHTTime >= dhtInterval) {
    previousDHTTime = currentMillis;  // Reset this task's timer
    float temperature = dht.readTemperature();
    float humidity = dht.readHumidity();

    // Send data to cloud
    sendDataToCloud(temperature, humidity);

  }

  // 3. Check the MQ2 Task ⏱️
  if (currentMillis - previousMQ2Time >= mq2Interval) {
    previousMQ2Time = currentMillis;  // Reset this task's timer

    float gas = analogRead(MQ2_PIN);

    // Send data to cloud
    sendDataToCloud(gas);
  }
}

This way we can perform multiple operations in specific intervals without blocking the loop function.

Conclusion

In this article we have seen how to perform multiple operations in specific intervals without blocking the loop function in ESP8266.

In next article we will use inbuilt task scheduler and itegrate with painlessmesh.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc