In-Memory Database with Backup and Restore
Question Details
Problem: In-Memory Database with Backup and Restore
Design and implement a simplified in-memory database that supports read/write on key-values and also supports backup and restore.
D
Full Details
Problem: In-Memory Database with Backup and Restore
Design and implement a simplified in-memory database that supports read/write on key-values and also supports backup and restore.
Data Model
- Each record is identified by a unique string
key. - Each record contains multiple fields, where each field name is a string
field. - Each field maps to an integer
value.
Operations (processed in order)
Process a sequence of commands and output results for specific commands.
1) SET key field value
- Set field under key to integer value.
- Create key or field if they do not exist.
-
No output.
2) GET key field
- If the value exists, print the integer; otherwise print NULL.
3) DELETE key field
- Remove field under key.
- If key has no remaining fields, remove the key as well.
-
No output.
4) BACKUP backup_id
- Save a full snapshot of the current database state under string id backup_id.
- If backup_id already exists, overwrite it.
-
No output.
5) RESTORE backup_id
- Restore the database state to the snapshot identified by backup_id.
- If backup_id does not exist, do nothing.
-
No output.
I/O Format
- First line: integer
Q(#commands). - Next
Qlines: one command per line. - Print one line per
GETcommand.
Constraints
- 1 <= Q <= 2 * 10^5
- key/field/backup_id contain lowercase letters and digits, length 1..20
- value fits in 32-bit signed int
- Should run efficiently (near O(Q) or O(Q log Q)).
Sample Input
10
SET a x 1
GET a x
BACKUP b1
SET a x 2
GET a x
RESTORE b1
GET a x
DELETE a x
GET a x
RESTORE b2
Sample Output
1
2
1
NULL
Test Cases
Case 1
Input:
10
SET a x 1
GET a x
BACKUP b1
SET a x 2
GET a x
RESTORE b1
GET a x
DELETE a x
GET a x
RESTORE b2
Output:
1
2
1
NULL
Case 2
Input:
7
GET k f
SET k f -5
GET k f
BACKUP s
DELETE k f
GET k f
RESTORE s
Output:
NULL
-5
NULL
Case 3
Input:
9
SET u p 10
SET u q 20
BACKUP t1
DELETE u p
GET u p
RESTORE t1
GET u p
DELETE u p
DELETE u q
Output:
NULL
10
Case 4
Input:
8
SET a b 1
BACKUP x
SET a c 2
BACKUP x
RESTORE x
GET a b
GET a c
GET a d
Output:
1
2
NULL
Case 5
Input:
6
SET a b 1
RESTORE none
GET a b
BACKUP s1
DELETE a b
GET a b
Output:
1
NULL
About This Question
This is a reported interview question from a instacart interview for a swe role during the coding round.
More Instacart Interview Questions
About Instacart Interview Reports
This question was reported by a candidate who interviewed at Instacart. LeakCode aggregates interview reports from 10+ sources, including 1Point3Acres, Glassdoor, LeetCode Discuss, Blind, Reddit, Indeed, and Nowcoder. Each report is translated where necessary, deduplicated against existing entries, and tagged by company, role, round type, and reporting date.
Use this question as one calibration data point, not a memorization target. Companies typically rotate their question pools every 2-4 months; the exact wording of a 2024 question may differ from what you encounter today. The underlying pattern, difficulty level, and follow-up depth at Instacart are the higher-signal extractions to take from this report.
For broader preparation context, the Instacart interview process typically includes a recruiter screen, one or two technical phone screens, and a 4-5 round on-site loop covering coding, system design (at L4+ levels), and behavioral. Reports tagged on LeakCode show the round-by-round distribution and typical difficulty calibration. To browse questions filtered by round type and seniority, use the company hub linked above.
How To Practice This Type of Question
Solve similar problems on LeetCode under timed conditions (25-35 minutes per medium difficulty). The goal is pattern recognition: recognize the underlying technique (sliding window, two-pointer, BFS, memoized recursion, etc.) within 60-90 seconds of reading. Strong candidates verbalize their hypothesis out loud before coding, then iterate based on feedback. Weak candidates dive into implementation immediately, lose time on the wrong approach, and run out of time for follow-ups.
Companies update their question pools every 2-4 months. The exact wording of any given question may have been retired by the time you interview. Focus your prep on the pattern, not the specific problem. The patterns that appear in Instacart reports consistently are the ones worth investing in; one-off niche problems are not.
During Your Instacart Round
Apply the standard interview round template: clarify requirements (2-3 minutes), state your approach out loud and confirm direction with the interviewer (3-5 minutes), code with narration (15-25 minutes), test with concrete examples including edge cases (5 minutes), discuss optimization or trade-offs if time permits (5 minutes). This template is universally accepted across FAANG and adjacent companies; deviating from it produces weaker interviewer feedback signal.
The single most predictive failure mode in Instacart reports tagged "no hire": not asking clarifying questions. Interviewers are explicitly trained to weight this. Strong candidates ask 3-5 clarifying questions even on problems that look obvious; weak candidates dive into code immediately. The clarifying-question check is often the first signal recorded in the interviewer's written notes.