Distributed counters pattern in Firebase - Commands & Configuration

Introduction

When many users update a counter at the same time, it can slow down or cause errors. The distributed counters pattern splits the count into pieces to handle many updates quickly and safely.

When you want to count likes on a popular post without delays or errors.

When many users vote or click a button at the same time and you need an accurate total.

When you track views on a video that gets thousands of views per second.

When you want to avoid your database slowing down because too many updates happen at once.

When you want to keep a total count but allow many small updates to happen separately.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /counters/{counterId} {
      allow read: if true;
      allow write: if request.auth != null;
    }
    match /counterShards/{shardId} {
      allow read: if true;
      allow write: if request.auth != null;
    }
  }
}

This security rules file allows authenticated users to read and write to the main counter document and its shards. It ensures only signed-in users can update counts, protecting your data from unauthorized changes.

Commands

Initialize Firestore in your Firebase project to start using the database for counters.

Terminal

firebase init firestore

Expected Output

=== Firestore Setup ===

You are about to initialize Firestore in your project.



Firestore rules and indexes files have been created.

Deploy the Firestore security rules to protect your counters and shards from unauthorized access.

Terminal

firebase deploy --only firestore:rules

Expected Output

=== Deploying to 'your-project-id'...



✔  firestore: rules deployed successfully



Project Console: https://console.firebase.google.com/project/your-project-id/firestore

→

--only firestore:rules - Deploy only Firestore security rules without affecting other services

Run a script that updates one shard of the distributed counter to safely increment the count.

Terminal

node updateCounterShard.js

Expected Output

Shard updated successfully with increment 1

Run a script that reads all shards and sums their counts to get the total counter value.

Terminal

node getTotalCount.js

Expected Output

Total count is 1234

Key Concept

If you remember nothing else from this pattern, remember: split a big counter into many small pieces to handle many updates safely and quickly.

Common Mistakes

Updating the main counter document directly for every increment.

This causes conflicts and slows down the database when many users update at once.

Update only one shard document per increment and sum shards to get the total.

Not setting proper security rules for shards.

Anyone could change counts, causing wrong totals or data loss.

Use Firestore rules to allow writes only from authenticated users.

Reading only one shard to get the total count.

You get an incomplete count because the total is spread across shards.

Read all shards and add their counts to get the correct total.

Summary

Initialize Firestore and set security rules to protect your counters.

Use multiple shard documents to split the counter for safe concurrent updates.

Update one shard at a time and sum all shards to get the total count.

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