Implement a Middle-Tier REST API Server for Camera Log Ingestion and Queries
VerkadaSoftware Engineer · Technical ScreenLast updated
Implement a middle-tier REST API server that lets cameras upload their logs and lets users request them back, with fake logs supplied by the tests. It tests endpoint design, request validation and status codes, storage organized for time-range queries, and thread-safe request handling.
Cameras produce logs. Implement the middle-tier API server that sits between users and cameras: cameras send their logs to the server, and users send requests to the server to get those logs back. Where the logs come from is out of scope. The tests create fake logs and exercise only the API's behavior, so your job is the HTTP interface, its request handling, and whatever storage it needs to answer requests.
Write the server by hand in a language and HTTP framework of your choice, including routing, request parsing, validation, and response codes. A lightweight framework such as Flask is enough.
Constraints and Clarifications
- Log generation is out of scope. Assume a camera, or a test acting as one, calls your API with log data.
- The exercise is about API behavior. Persistence beyond the life of the process is not required unless the interviewer asks for it.
Clarifying Questions
- What fields does a log entry have (for example, a timestamp, a severity, a message), and do cameras send one entry per request or batches?
- Which queries do users need: all logs for one camera, a time range, the most recent entries, or filtering by severity?
- Do users only read logs, or can they also send a request that the server must relay to a camera?
- How should the server respond to unknown cameras, malformed entries, or duplicate submissions?
- Is there a limit on how many entries a single response may return, and should results be paginated?
- Do requests need authentication, for example to stop one user from reading another user's cameras?
Hints
Hint 1
Pin down the contract before the handlers: Write out each endpoint's method, path, request body, success response, and error responses before you write any handler. Much of the difficulty in this exercise lies in understanding exactly which behavior is expected.
Hint 2
Store logs for the questions users ask: Organize what the server keeps around the lookups users will make, so that answering a request does not mean scanning every log from every camera.
Follow-up questions
- Many cameras now send logs continuously. What breaks first in your server, and how would you scale ingestion and storage?
- Users want new logs pushed to them as they arrive instead of polling. How would you change the API?
- A camera times out and resends the same batch. How do you avoid storing the entries twice?
- Logs may be kept only for a limited period. How would you enforce retention without slowing down requests?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.