Stream vs polling comparison in DynamoDB - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding DynamoDB Streams vs Polling

Which of the following best describes a key advantage of using DynamoDB Streams over polling to detect data changes?

A Streams only work for batch updates, while polling detects individual item changes instantly.

B Polling requires less infrastructure setup and automatically scales better than streams.

C Streams provide near real-time change data capture without continuous querying, reducing latency and cost.

D Polling is event-driven and pushes changes to clients, while streams require manual fetching.

💡 Hint

Think about how each method detects changes and the impact on latency and resource use.

DynamoDB Streams capture changes as they happen and allow applications to react quickly without repeatedly querying the database. Polling requires frequent queries, increasing latency and cost.

❓ query_result

intermediate

Polling Query Result Behavior

Given a DynamoDB table with 1000 items, if you poll the table every 5 seconds to detect changes, what is the expected behavior regarding data freshness and cost?

A Polling returns the entire table each time, causing high read costs and potential stale data between polls.

B Polling triggers DynamoDB Streams internally to fetch only changes, reducing cost.

C Polling automatically caches changes, so costs remain low and data is always fresh.

D Polling every 5 seconds returns only changed items, minimizing read costs.

💡 Hint

Consider what a typical scan or query does when polling without change tracking.

Polling usually involves scanning or querying the table repeatedly, which reads all items and incurs high costs. Data freshness depends on the polling interval, so changes between polls may be missed.

❓ optimization

advanced

Optimizing Change Detection with Streams

You want to process only new changes from a DynamoDB Stream without reprocessing old records. Which approach ensures efficient and correct processing?

A Store the last processed sequence number and use it to continue reading from the stream where you left off.

B Read the entire stream from the beginning every time to avoid missing any changes.

C Poll the table for changes and ignore the stream to reduce complexity.

D Use a random starting point in the stream to balance load and avoid duplicates.

💡 Hint

Think about how to avoid duplicate processing and missing data in a continuous stream.

By storing the last processed sequence number, you can resume reading the stream from that point, ensuring no duplicates or missed changes. Reading from the start every time is inefficient and causes duplicates.

🔧 Debug

advanced

Identifying Polling Issues in DynamoDB

You implemented polling every 10 seconds on a large DynamoDB table to detect changes. Users report delays and high AWS costs. What is the most likely cause?

A Polling triggers Lambda functions too frequently, causing throttling.

B Polling uses DynamoDB Streams internally, which is slower than direct queries.

C Polling caches results locally, causing stale data to be shown to users.

D Polling scans the entire table each time, causing high read throughput and delayed detection.

💡 Hint

Consider what happens when scanning a large table repeatedly.

Polling by scanning the entire table every 10 seconds consumes a lot of read capacity and causes delays because the scan takes time. This leads to higher costs and slower updates.

🧠 Conceptual

expert

Choosing Between Streams and Polling for Real-Time Applications

For a real-time notification system that must react instantly to data changes with minimal cost, which approach is best and why?

A Use frequent polling because it is simpler to implement and scales better for real-time needs.

B Use DynamoDB Streams because they provide event-driven, near real-time updates with lower read costs than polling.

C Use a combination of polling and streams to balance cost and latency equally.

D Use polling with a long interval to reduce costs and accept delayed notifications.

💡 Hint

Think about event-driven vs repeated querying and their impact on latency and cost.

DynamoDB Streams push changes as events, enabling instant reactions with less overhead. Polling repeatedly queries the database, increasing cost and latency, making streams better for real-time systems.

Practice

1. Which of the following best describes DynamoDB Streams compared to polling?

easy

A. Polling and streams both check for changes only once a day.

B. Polling pushes data changes immediately, streams check periodically.

C. Streams push data changes immediately, polling checks periodically.

D. Both streams and polling push data changes immediately.

Solution

1. Step 1: Understand DynamoDB Streams behavior

   DynamoDB Streams send data change events as they happen, pushing updates immediately.

2. Step 2: Understand polling behavior

   Polling requires the client to ask for updates at fixed intervals, not instantly.

3. Final Answer:

   Streams push data changes immediately, polling checks periodically. -> Option C

4. Quick Check:

   Streams = push, Polling = periodic check [OK]

Hint: Streams push instantly; polling waits for your request [OK]

Common Mistakes:

• Confusing which method pushes data
• Thinking polling is real-time
• Assuming streams require manual checks

2. Which syntax correctly represents enabling DynamoDB Streams on a table using AWS CLI?

easy

A. aws dynamodb update-table --table-name MyTable --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE

B. aws dynamodb enable-stream --table MyTable --type NEW_IMAGE

C. aws dynamodb create-stream --table-name MyTable --view NEW_IMAGE

D. aws dynamodb set-stream --table MyTable --enabled true

Solution

1. Step 1: Identify correct AWS CLI command for streams

   The correct command to enable streams is 'update-table' with '--stream-specification' option.

2. Step 2: Verify syntax correctness

   aws dynamodb update-table --table-name MyTable --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE uses correct flags and parameters: StreamEnabled=true and StreamViewType=NEW_IMAGE.

3. Final Answer:

   aws dynamodb update-table --table-name MyTable --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE -> Option A

4. Quick Check:

   Enable streams with update-table and stream-specification [OK]

Hint: Use update-table with --stream-specification to enable streams [OK]

Common Mistakes:

• Using non-existent commands like create-stream
• Incorrect flag names
• Missing StreamEnabled parameter

3. Given a DynamoDB table with streams enabled, what will happen if you poll the table every 10 minutes instead of using streams?

medium

A. Polling disables streams temporarily.

B. You get real-time updates as soon as data changes.

C. Polling automatically triggers streams to push data.

D. You receive updates only every 10 minutes, possibly missing immediate changes.

Solution

1. Step 1: Understand polling frequency impact

   Polling every 10 minutes means updates are checked only at those intervals, not instantly.

2. Step 2: Compare with streams behavior

   Streams push changes immediately, so polling delays updates and may miss real-time events.

3. Final Answer:

   You receive updates only every 10 minutes, possibly missing immediate changes. -> Option D

4. Quick Check:

   Polling = delayed updates, not real-time [OK]

Hint: Polling delays updates; streams push instantly [OK]

Common Mistakes:

• Assuming polling is real-time
• Thinking polling triggers streams
• Believing polling disables streams

4. You wrote code to poll a DynamoDB table every 5 seconds but notice high latency and missed updates. What is the likely issue?

medium

A. Streams must be disabled to use polling.

B. Polling too frequently causes throttling and delays.

C. Polling automatically disables table writes.

D. Polling every 5 seconds guarantees no missed updates.

Solution

1. Step 1: Analyze polling frequency effects

   Polling very frequently can cause throttling or API limits, increasing latency.

2. Step 2: Understand polling limitations

   Polling does not guarantee no missed updates and can overload the system if too frequent.

3. Final Answer:

   Polling too frequently causes throttling and delays. -> Option B

4. Quick Check:

   Too frequent polling = throttling and latency [OK]

Hint: Avoid polling too often to prevent throttling [OK]

Common Mistakes:

• Thinking streams must be off to poll
• Believing polling disables writes
• Assuming frequent polling prevents missed updates

5. You need to build a dashboard that updates instantly when DynamoDB data changes. Which approach is best and why?

hard

A. Use DynamoDB Streams to push changes and update dashboard in real-time.

B. Poll the table every hour to reduce costs and update dashboard.

C. Disable streams and poll every 5 minutes for near real-time updates.

D. Use polling once a day and cache results for dashboard.

Solution

1. Step 1: Identify real-time update requirement

   The dashboard needs instant updates when data changes, requiring immediate notification.

2. Step 2: Compare streams and polling for real-time needs

   Streams push changes immediately, ideal for real-time dashboards; polling delays updates and is less efficient.

3. Final Answer:

   Use DynamoDB Streams to push changes and update dashboard in real-time. -> Option A

4. Quick Check:

   Real-time dashboard = use streams [OK]

Hint: For instant updates, prefer streams over polling [OK]

Common Mistakes:

• Choosing polling despite real-time need
• Ignoring cost vs latency trade-offs
• Assuming polling can be truly real-time