Product and System Design: Replace Hotel Metal Keys With Electronic Keycards
A hotel chain currently uses traditional metal keys and wants to migrate to electronic keycards across guest rooms, amenities, elevators, and staff-only areas. Design the end-to-end product and system at a high level.
Constraints & Assumptions
-
Support guest access and staff access for a multi-property hotel environment.
-
The solution must work during network outages and common hotel failure modes.
-
Treat guest privacy, physical safety, and operational continuity as first-class requirements.
-
Avoid relying on obsolete card security models; assume modern cryptographic credentials are available.
Clarifying Questions to Ask
-
Is this for one property, a regional rollout, or a global hotel chain?
-
Do we need mobile keys in v1, or only physical keycards?
-
What systems already exist, such as property management, loyalty, elevators, and staff scheduling?
-
What level of offline operation is required when door locks cannot reach a server?
Part 1 - Strategic and Customer Rationale
Explain why the hotel should replace metal keys with electronic keycards. Address benefits for guests, hotel staff, and the business.
What This Part Should Cover
-
Convenience, reissuance, safety, operational efficiency, and auditability.
-
Benefits for front desk, housekeeping, maintenance, security, and guests.
-
Business impact such as lower rekeying cost, faster check-in, and reduced risk.
Part 2 - Product Requirements
Define the must-have features for check-in, check-out, lost-card handling, staff access, role-based permissions, auditing, and integrations.
What This Part Should Cover
-
The core user flows for guest, front desk, kiosk, mobile, and staff use cases.
-
Access roles, time windows, revocation, room changes, and amenity access.
-
Reporting, device management, and integration with hotel systems.
Part 3 - High-Level Architecture
Describe the architecture connecting cards, encoders, locks, property software, edge services, cloud services, and key management.
What This Part Should Cover
-
How credentials are issued, stored, verified, expired, and synchronized.
-
How offline locks validate a card while still supporting revocation.
-
Trade-offs between symmetric credentials, signed credentials, online validation, and offline validation.
Part 4 - Security and Failure Modes
Propose mitigations for card cloning, brute-force attempts, replay attacks, packet interception, insider misuse, power outages, dead lock batteries, and server downtime.
What This Part Should Cover
-
Cryptography, key rotation, secure hardware, audit logs, rate limits, and least privilege.
-
Practical hotel operations such as service cards, battery monitoring, emergency override, and incident response.
-
Privacy protections that avoid storing unnecessary personal data on the card.
What a Strong Answer Covers
-
A product answer and a system answer, not only one of the two.
-
Clear treatment of security, revocation, and offline reliability.
-
Realistic operational flows for hotels rather than a purely theoretical architecture.
Follow-up Questions
-
How would you revoke a lost card if the door lock is offline?
-
What data should never be stored on the card?
-
How would you support mobile keys later?
-
What would you monitor after rollout?
-
How would you migrate a hotel without disrupting current guests?
