Design a constrained cache and secure string validator

## Part A — Constrained cache (LRU-like) Design an in-memory cache that supports the following operations: - `get(key) -> value | null` - `put(key, value) -> void` ### Functional requirements - The cache has a fixed capacity `C` (number of entries). When inserting into a full cache, evict an entry based on a well-defined policy (e.g., least-recently-used). - `get` and `put` should be efficient (target amortized \(O(1)\)). ### Security/robustness requirements (discuss + implement) - **High concurrency:** multiple threads may call `get/put` concurrently. Describe and/or implement a thread-safe approach. - **Abuse scenarios:** discuss how the cache behaves under: - extremely hot keys (contention), - key-spamming (many unique keys), - intentionally malformed/oversized keys or values. - **Failure handling:** define behavior for null/empty keys, capacity \(C \le 0\), memory pressure, and unexpected exceptions. ## Part B — Secure string validation (IP-like) Write a function `classifyAddress(s: string) -> "IPv4" | "IPv6" | "Neither"`. ### Core rules (typical IPv4/IPv6 validation) - IPv4: four decimal segments separated by `.`, each `0..255`, no leading `+/-`, no extra spaces; handle leading zeros per your chosen policy but state it clearly. - IPv6: eight hex segments separated by `:`, each `1..4` hex chars (`0-9`, `a-f`, `A-F`). ### Security constraints (must address) - **Bypass resistance:** your parser must not accept inputs that can trick naive implementations (e.g., hidden whitespace, mixed separators, Unicode lookalikes, overflow like `9999999999`, empty segments, trailing separators). - **Performance under abnormal traffic:** avoid worst-case blowups (e.g., pathological long strings). State time and space complexity and any length limits you enforce. Return the classification string for each input.