Backend Developer project
Build a high-write analytics endpoint with aggregated reads
An event-ingestion endpoint built to survive real write volume, plus a read endpoint that aggregates correctly — the two halves of any analytics feature.
The brief
Build an endpoint that accepts event pings (e.g. page_view, click, signup) at high write volume without writing to the database on every single request — batch or queue writes instead. Build a second read endpoint that returns aggregated event counts by day for a given date range. Load-test the write path locally and record the result.
Suggested stack
What you hand in
- A public GitHub repository with the API and a README
- A load test result (e.g. output from wrk or autocannon) pasted into the README with a short note on what it shows
- A note explaining the batching/queueing approach and the indexing decisions behind the aggregation query
Grading happens against the rubric below, so read it before you start — not after.
How this is graded
Published in advance and weighted out of 100. Nothing here is a surprise.
The write path uses batching, queueing, or bulk inserts instead of one DB write per event, and the load test result shows it holding up under a meaningful request rate.
The read endpoint returns correct daily counts for an arbitrary date range, backed by an index on the timestamp/date column, not a full table scan.
The events table is structured for the access pattern actually used (write-heavy, range-queried by date), not a generic key-value blob.
Both endpoints validate input, return sensible status codes, and the read endpoint's date range parameters are documented.
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- Event/analytics ingestion is a common real ticket, and the naive per-request-write version is the one that falls over first in production.
- Indexing discipline on a date/timestamp column is a small decision with an outsized effect on query time as data grows, and it's exactly the kind of thing a senior engineer checks first.
- The load test result makes the write-path performance claim checkable rather than a matter of opinion.
Where people lose points
- Writing to the database synchronously on every single event, so the endpoint's latency and failure rate scale with database load.
- Missing an index on the date/timestamp column, so the aggregation query works fine in a small test but scans the whole table in practice.
- Aggregating in application code after pulling every matching row into memory instead of letting the database do the grouping.
Other Backend Developer projects
Two or three of these turn an empty resume into a portfolio.
Built it? Get it scored against this rubric.
Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.