Each request inside a fixed time increases a counter. Once the counter reaches the maximum allowed number, all further attempts are rejected.

Pro:

  • Newer attempts are not starved by old ones.
  • Low storage cost.

Con:

A burst of attempts near the boundary of a window can result in a very high request rate because two windows will be filled with attempts quickly.

IMPORT_PATH: "@daiso-tech/core/rate-limiter/policies"

Implements

Constructors

Methods

  • Calculates the expiration date for the current metrics. Determines when the rate limiter state should be automatically cleaned up.

    This method is critical for persistence: data persisted beyond this date should be deleted. If this method returns a date in the past, the adapter should treat the rate limiter as expired and allow requests with fresh metrics calculation.

    Common patterns:

    • Fixed-window: Return date of window end (e.g., start + duration)
    • Sliding-window: Return earliest tracked request + duration

    Parameters

    Returns Date

    Date when this rate limiter state should expire and be cleaned up

  • Determines if the rate limiter should block the current request. Evaluates current metrics against the configured limit. Returns true if the attempt limit has been exceeded (request should be blocked).

    Parameters

    • currentMetrics: FixedWindowLimiterState

      The current tracking metrics

    • limit: number

      Maximum allowed attempts in the window

    • currentDate: Date

      Current date/time for window boundary checks

    Returns boolean

    true if request should be blocked, false if allowed