Quick Overview

Implement authentication tokens with a fixed time to live across generate, renew, and count operations. Respect the exact expiry boundary, ignore renewal of missing or expired tokens, handle replacement, and scale cleanup to a large timestamp-ordered operation stream.

Manage Authentication Tokens with a Fixed Time to Live

Company: IBM

Role: Software Engineer

Category: Coding & Algorithms

Difficulty: medium

Interview Round: Online Assessment

## Problem Implement an authentication manager with a fixed `timeToLive`. `generate(tokenId, currentTime)` creates or replaces a token whose expiry is `currentTime + timeToLive`. `renew(tokenId, currentTime)` extends an existing token to `currentTime + timeToLive` only if it is still unexpired. `count(currentTime)` returns the number of unexpired tokens. Process operations in strictly increasing time order and return the result of each count operation. ### Constraints & Assumptions - There are at most 200,000 operations and `1 <= timeToLive <= 1,000,000,000`. - Every `currentTime` is an integer in `[1, 1,000,000,000,000]`, so every computed expiry is at most `1,001,000,000,000`, below `2^53`, and exactly representable across all four languages. - Token IDs are non-empty strings. - A token is expired when `currentTime >= expiryTime`. - Renewing a missing or expired token has no effect. ### Clarifications - Generating an existing token ID replaces its previous expiry. - Operation times are strictly increasing, so expired entries never become active again without generate. - Only count results are included in the returned list. ### Examples ```text timeToLive = 5 operations = [generate("a", 1), renew("a", 2), count(6), count(7)] output = [1, 0] ``` ### Hints ```hint Store authoritative expiry A map can tell whether a token's latest expiry is after the current time. ``` ```hint Discard stale expiration records If using an expiry-ordered queue, a token may have been renewed since an older queue item was created. ```

Quick Answer: Implement authentication tokens with a fixed time to live across generate, renew, and count operations. Respect the exact expiry boundary, ignore renewal of missing or expired tokens, handle replacement, and scale cleanup to a large timestamp-ordered operation stream.

Process a fresh authentication manager with fixed timeToLive. Each operation is ["generate", tokenId, currentTime], ["renew", tokenId, currentTime], or ["count", currentTime], and operation times are strictly increasing. Generate creates or replaces a token with expiry currentTime + timeToLive. Renew extends an existing token only when it is still unexpired. A token is expired when currentTime is at least its expiry. Count reports the number of unexpired tokens. Return only count results in operation order.

Constraints

  • 1 <= timeToLive <= 1000000000.
  • operations contains at most 200000 encoded generate, renew, or count lists.
  • Token IDs are non-empty strings.
  • Every currentTime is an integer in [1, 1000000000000], and times strictly increase across the batch.
  • Every computed expiry is at most 1001000000000 and is exactly representable across all four languages.
  • A token is expired when currentTime >= expiryTime.
  • Only count results are returned.

Examples

Input: (5, [['generate', 'a', 1], ['renew', 'a', 2], ['count', 6], ['count', 7]])

Expected Output: [1, 0]

Explanation: This is the source example; renewal moves a's expiry from 6 to 7.

Input: (10, [])

Expected Output: []

Explanation: No count operations produce an empty result.

Hints

  1. Store each token's authoritative latest expiry in a map.
  2. When popping an expiry queue record, verify that it is still the token's current expiry.

Loading coding console...