DynamoDB pagination lacking native reverse navigation support

Amazon DynamoDB does not provide a native "previous page" mechanism because its pagination model is stateless and cursor-based. To implement backward navigation, you must either maintain a client-side stack of cursors or utilize a reversed sort order for specific requests.

Architectural Patterns for Backward Navigation

Since the API does not track request history, you can use one of the following two patterns depending on your UX requirements:

1. The Cursor Stack (Stateful Tracking)

The most common pattern is maintaining a stack of ExclusiveStartKey values. As the user moves forward, the application pushes the current page's starting key onto a stack. When the user clicks "Previous," the application pops the last key from the stack and executes a new request.

• Forward: Store current ExclusiveStartKey $\rightarrow$ Request next page $\rightarrow$ Store LastEvaluatedKey.
• Backward: Pop previous key from stack $\rightarrow$ Request page using that key as ExclusiveStartKey.

2. Inverted Sort Order (Stateless Reversal)

If you need to navigate backward from a specific known item without a history stack, you can use the ScanIndexForward parameter. By setting ScanIndexForward = false, DynamoDB traverses the index in reverse chronological or alphabetical order (depending on your sort key).

Note: This does not provide a "previous page" in the traditional sense; it provides the items immediately preceding the current cursor in reverse order. To return to the original forward flow, you must toggle ScanIndexForward back to true.

Impact of the 1MB Response Limit

The 1MB response size limit does not directly affect the reliability of caching keys, but it significantly impacts the frequency of key generation. Because DynamoDB may return a LastEvaluatedKey even if the result set is small (if the 1MB limit was hit during the scan), a user may traverse many "pages" of cursors despite viewing relatively few items.

This increases the memory footprint of your client-side stack. In deep-page traversal, the number of cached keys grows linearly with the number of requests, not necessarily the number of items. This makes the cursor stack more memory-intensive for datasets with large item sizes.

Verification Steps

To verify these behaviors in your environment:

1. Execute a Query with a small Limit to trigger a LastEvaluatedKey.
2. Pass that key as the ExclusiveStartKey to verify forward movement.
3. Execute the same query with ScanIndexForward = false to confirm the result set is inverted.

Diagnostic Detail: Are you implementing this for a web-based UI (where URL state is preferred) or a mobile application (where in-memory state is more viable)? This determines whether you should encode the cursor stack into the URL or a local cache.