Problem statement
Design the object model and access APIs for a smart door lock that grants or denies entry from multiple credential types, honours per-credential access schedules, and records an audit trail.
Operating context. One lock guards one door. Entry is attempted with a credential: a numeric PIN, an RFID fob, or an app-issued one-time code. Each credential belongs to a user and carries an access policy (always, weekdays 9-5, a guest window valid Fri-Sun, or single-use). On an attempt the manager verifies the credential and evaluates its schedule against the current time, then engages or refuses the deadbolt and appends an audit entry. An operator can add, revoke, or suspend credentials at any time. The lock also auto-relocks after a timeout. Everything runs in-process on the lock.
Out of scope. The cloud account service and its sync endpoints, the BLE/Wi-Fi transport and pairing handshake, cryptographic key storage / secure-element internals, the mobile app UI, and tamper/forced-entry hardware detection.
What to produce. The class hierarchy (lock, deadbolt actuator, credential hierarchy, access policy, access manager, audit log), the public API each class exposes, and the state transitions for the deadbolt. Be explicit about: how a new credential type is added without editing the verify path, how time-window and single-use policies plug in as a Strategy, and how concurrent unlock attempts on the same lock are serialised so a single-use code cannot be spent twice.
Functional requirements
- Verify a presented credential and, on success, evaluate its access policy against the current time before deciding to unlock.
- Engage or refuse the deadbolt based on the combined verify-and-policy result, and auto-relock after a configured timeout.
- Let an operator add, revoke, or temporarily suspend credentials, taking effect on the next attempt.
- Consume a single-use or one-time code exactly once so a replay of the same code is denied.
- Append an immutable audit entry for every attempt (who, when, credential type, granted or denied, reason).
- Report status: current deadbolt state, count of active credentials, and the most recent access events.
Non-functional requirements
- Adding a new credential type is a localised change: the verify path must not switch on concrete credential types.
- Access policies are pluggable Strategies so a new time-window or usage rule is added without editing the manager core.
- Concurrent unlock attempts on one lock are serialised so a single-use code can never be redeemed twice.
- The deadbolt is a well-defined thread-safe state machine that always resolves to locked or unlocked, never an in-between limbo.
- The design is unit-testable without real hardware or wall-clock time, with clock, deadbolt driver, and audit sink injected.
- The audit log is append-only from the manager's perspective, exposing no mutation of past entries.
Topics
- System Design LLD
- Oop Solid
- Patterns Strategy
- Concurrency Mutual-Exclusion
- Iot Access-Control