Distributed counters pattern in Firebase - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to initialize a distributed counter document reference in Firebase.

Firebase

const counterRef = firestore.collection('counters').doc([1]);

Drag options to blanks, or click blank then click option'

A'counterDoc'

B'counter'

C'distributedCounter'

D'countDoc'

Attempts:

3 left

💡 Hint

Common Mistakes

Using a collection name instead of a document ID.

Leaving the document ID empty or undefined.

The document ID 'distributedCounter' clearly identifies the counter document in the 'counters' collection.

2fill in blank

medium

Complete the code to increment a shard's count atomically using a transaction.

Firebase

await firestore.runTransaction(async (transaction) => {
  const shardRef = counterRef.collection('shards').doc([1]);
  const shardDoc = await transaction.get(shardRef);
  if (!shardDoc.exists) {
    transaction.set(shardRef, { count: 1 });
  } else {
    transaction.update(shardRef, { count: shardDoc.data().count + 1 });
  }
});

Drag options to blanks, or click blank then click option'

A'shard0'

B'shard1'

C'shardA'

D'shardX'

Attempts:

3 left

💡 Hint

Common Mistakes

Using shard IDs that do not match the naming convention.

Using an undefined or empty shard ID.

Using 'shard0' as the shard document ID is a common pattern to identify one shard among many.

3fill in blank

hard

Fix the error in the code to correctly sum counts from all shards.

Firebase

const shardsSnapshot = await counterRef.collection('shards').get();
let totalCount = 0;
shardsSnapshot.forEach(doc => {
  totalCount += doc.data().[1];
});

Drag options to blanks, or click blank then click option'

Avalue

Btotal

Cnumber

Dcount

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect field names like 'value' or 'total' which do not exist.

Assuming the field is named 'number' instead of 'count'.

The field storing the count in each shard document is named 'count'.

4fill in blank

hard

Fill both blanks to create a function that initializes shards with zero counts.

Firebase

async function initializeShards(counterRef, numShards) {
  const batch = firestore.batch();
  for (let i = 0; i < numShards; i++) {
    const shardRef = counterRef.collection('shards').doc([1]);
    batch.set(shardRef, { [2]: 0 });
  }
  await batch.commit();
}

Drag options to blanks, or click blank then click option'

A`shard${i}`

Bcount

Cvalue

D`shard_${i}`

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect shard naming without template literals.

Using wrong field names like 'value' instead of 'count'.

The shard document IDs use template literals like `shard${i}` to create unique shard names. The count field is named 'count' and initialized to 0.

5fill in blank

hard

Fill all three blanks to implement a function that reads and sums counts from all shards.

Firebase

async function getDistributedCount(counterRef) {
  const shardsSnapshot = await counterRef.collection([1]).get();
  let totalCount = 0;
  shardsSnapshot.forEach(doc => {
    totalCount += doc.data()[[2]];
  });
  return totalCount;
}

const count = await getDistributedCount([3]);

Drag options to blanks, or click blank then click option'

A'shards'

B'count'

CcounterRef

D'counters'

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong collection names like 'counters' instead of 'shards'.

Using incorrect field names or passing wrong arguments.

The function reads from the 'shards' collection, sums the 'count' field from each shard, and is called with the counterRef.

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