Distributed counters pattern in Firebase - Mini Project: Build & Apply

Distributed Counters Pattern with Firebase

📖 Scenario: You are building a simple app that counts how many times users click a button. To handle many users clicking at the same time without slowing down, you will use the distributed counters pattern in Firebase.

🎯 Goal: Create a Firebase Firestore structure to store distributed counters, configure the number of shards, write code to increment the counter safely, and finalize the counter document with the total count.

📋 What You'll Learn

Create a Firestore collection with a document for the counter

Add a configuration for the number of shards

Write a function to increment a random shard's count

Add a field to store the total count in the main counter document

💡 Why This Matters

🌍 Real World

Distributed counters help apps handle many users updating the same count without conflicts or slowdowns.

💼 Career

Understanding distributed counters is important for building scalable cloud applications that handle high traffic.

1

Create the main counter document

Create a Firestore collection called counters and add a document with ID clicks that has a field totalCount set to 0.

Firebase

// Your code here to create the counters collection and clicks document with totalCount 0

Hint

Use firestore.collection('counters').doc('clicks').set({ totalCount: 0 }) to create the document.

2

Add shard count configuration

Create a constant called NUM_SHARDS and set it to 5 to define how many shards the counter will use.

Firebase

const countersRef = firestore.collection('counters').doc('clicks');
await countersRef.set({ totalCount: 0 });
// Define the number of shards
// Your code here

Hint

Use const NUM_SHARDS = 5; to set the shard count.

3

Write function to increment a random shard

Write a function called incrementCounter that picks a random shard number from 0 to NUM_SHARDS - 1 and increments the count field in that shard document inside counters/clicks/shards collection using a transaction.

Firebase

const countersRef = firestore.collection('counters').doc('clicks');
await countersRef.set({ totalCount: 0 });
const NUM_SHARDS = 5;

// Write incrementCounter function
// Your code here

Hint

Use Math.floor(Math.random() * NUM_SHARDS) to pick a shard. Use a transaction to safely update the shard's count.

4

Add total count field update

Add a field totalCount to the clicks document that will store the total count of all shards. Update the incrementCounter function to increment this totalCount field inside the same transaction.

Firebase

const countersRef = firestore.collection('counters').doc('clicks');
await countersRef.set({ totalCount: 0 });
const NUM_SHARDS = 5;

async function incrementCounter() {
  const shardId = Math.floor(Math.random() * NUM_SHARDS).toString();
  const shardRef = countersRef.collection('shards').doc(shardId);
  await firestore.runTransaction(async (transaction) => {
    const shardDoc = await transaction.get(shardRef);
    if (!shardDoc.exists) {
      transaction.set(shardRef, { count: 1 });
    } else {
      const newCount = (shardDoc.data().count || 0) + 1;
      transaction.update(shardRef, { count: newCount });
    }
    // Update totalCount field here
    // Your code here
  });
}

Hint

Inside the transaction, get the main counter document and update its totalCount by adding 1.

Practice

1. What is the main reason to use the distributed counters pattern in Firebase?

easy

A. To avoid write conflicts by splitting counts into multiple shards

B. To store large files efficiently

C. To speed up user authentication

D. To reduce network bandwidth usage

Solution

1. Step 1: Understand the problem with single counters

   Single counters cause write conflicts when many users update at once.

2. Step 2: How distributed counters solve this

   Splitting the count into shards lets many users write to different parts, avoiding conflicts.

3. Final Answer:

   To avoid write conflicts by splitting counts into multiple shards -> Option A

4. Quick Check:

   Distributed counters = avoid conflicts [OK]

Hint: Distributed counters split counts to avoid conflicts [OK]

Common Mistakes:

• Thinking it speeds up authentication
• Confusing with file storage
• Assuming it reduces bandwidth

2. Which Firebase data structure is typically used to implement shards in a distributed counter?

easy

A. A single document with a numeric field

B. A collection of user profiles

C. Multiple documents each representing a shard

D. A storage bucket

Solution

1. Step 1: Identify how shards are stored

   Each shard is stored as a separate document to allow independent updates.

2. Step 2: Why multiple documents

   Multiple documents reduce write conflicts by spreading writes across shards.

3. Final Answer:

   Multiple documents each representing a shard -> Option C

4. Quick Check:

   Shards = multiple documents [OK]

Hint: Shards are separate documents, not single fields [OK]

Common Mistakes:

• Using a single document for all shards
• Confusing shards with user profiles
• Thinking shards are stored in storage buckets

3. Given this code snippet to increment a distributed counter shard in Firebase Firestore, what is the expected behavior?

const shardId = Math.floor(Math.random() * 5);
const shardRef = firestore.collection('counters').doc('counter1').collection('shards').doc(shardId.toString());
await shardRef.update({ count: firebase.firestore.FieldValue.increment(1) });

medium

A. It increments the count in a random shard to reduce write conflicts

B. It increments the count in all shards simultaneously

C. It causes an error because shardId is a number

D. It resets the count to 1 in the selected shard

Solution

1. Step 1: Understand shard selection

   The code picks a random shard ID between 0 and 4 to update.

2. Step 2: What update does

   It increments the count field in that shard by 1, avoiding conflicts.

3. Final Answer:

   It increments the count in a random shard to reduce write conflicts -> Option A

4. Quick Check:

   Random shard increment = reduce conflicts [OK]

Hint: Random shard update avoids conflicts [OK]

Common Mistakes:

• Thinking it updates all shards at once
• Assuming shardId type causes error
• Believing it resets count instead of incrementing

4. You have a distributed counter with 3 shards but the total count is incorrect. Which of these is a likely cause?

medium

A. You incremented the same shard multiple times

B. You forgot to sum all shard counts when reading the total

C. You used a single document instead of shards

D. You used a random shard for increments

Solution

1. Step 1: Check how total count is calculated

   Total count must be the sum of all shard counts.

2. Step 2: Identify missing sum

   If you read only one shard or forget to sum, total will be wrong.

3. Final Answer:

   You forgot to sum all shard counts when reading the total -> Option B

4. Quick Check:

   Sum all shards for total [OK]

Hint: Always sum all shards to get total count [OK]

Common Mistakes:

• Assuming incrementing same shard causes wrong total
• Confusing single document with shards
• Thinking random shard increments cause errors

5. You want to design a distributed counter with 10 shards for a high-traffic app. Which approach best balances accuracy and performance?

hard

A. Increment shards sequentially in a fixed order

B. Increment all shards on each update and read any one shard for total

C. Use a single document counter with transaction retries

D. Increment a random shard on each update and sum all shards when reading total

Solution

1. Step 1: Understand update strategy

   Incrementing a random shard spreads writes and avoids conflicts.

2. Step 2: Understand read strategy

   Summing all shards gives accurate total, though slightly delayed.

3. Step 3: Why other options fail

   Incrementing all shards wastes writes; single document causes conflicts; sequential increments cause bottlenecks.

4. Final Answer:

   Increment a random shard on each update and sum all shards when reading total -> Option D

5. Quick Check:

   Random increment + sum shards = best balance [OK]

Hint: Random increments + sum shards = best practice [OK]

Common Mistakes:

• Trying to increment all shards each time
• Using single document counter under high load
• Incrementing shards in fixed order causing bottlenecks