##### Question You are given a code snippet that implements an HTTP `GET /events` handler (`getEvents`). The handler queries events from a database and, for each event, lazily loads related data (for example venue, performers, tickets, and the transactions needed for downstream processing). Perform a thorough code review and propose concrete fixes across the following areas: 1. **Readability and architecture**: Identify duplicate code, poor naming/structure, unclear responsibilities (controller mixing transport, business logic, and SQL), leaky error handling, and the absence of explicit DTOs/response shapes. Propose a layered design (controller / service / repository), centralized validation and error handling, response DTOs with field whitelisting, and structured logging with correlation IDs. 2. **Performance**: Look for N+1 queries (loading related data per event in a loop), missing pagination/limits, inefficient sorting/filtering on non-indexed columns, post-fetch in-memory filtering, missing indexes, excessive serialization/over-fetching, uncompressed payloads, and missing caching or ETags. Propose batching/joins to eliminate N+1, enforced pagination (prefer keyset/cursor), composite indexes aligned to filter+sort patterns, projections/sparse fieldsets, compression, and conditional caching (ETag/Last-Modified, Cache-Control). 3. **Scalability**: Evaluate statelessness, connection pooling, dependency fan-out and batching, timeouts/retries with jitter, circuit breakers, backpressure/load shedding, rate limiting, and asynchronous precomputation/denormalization for hot listings. Propose concrete settings and trade-offs. 4. **Security**: Verify authentication and fine-grained authorization (scope/row-level access), input validation and SQL/NoSQL injection prevention (parameterized queries, sort/include allowlists), output encoding and PII minimization, TLS requirements, CSRF/IDOR risk, least-privilege DB roles, logging redaction, and resource quotas to prevent abuse. For each area, propose concrete fixes, explain the trade-offs, and outline correct HTTP status-code semantics. Finally, define the monitoring/alerting metrics and SLOs you would track, and a targeted test plan covering unit, integration, security (injection, authN/authZ), and performance/load tests (including a query-count budget that fails on N+1 regressions).

A StubHub software-engineer technical-screen system-design exercise: review and fix a GET /events HTTP handler that loads related data (venue, performers, tickets, transactions) per event. Candidates must find and fix the N+1 query, then harden the endpoint across readability/architecture, performance (pagination, indexing, caching), scalability (timeouts, retries, rate limiting), and security (authN/authZ, injection, PII), with trade-offs, SLOs, and a test plan.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at StubHub.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at StubHub during technical interviews.

Review getEvents endpoint for readability, performance, scalability, security

Question

You are given a code snippet that implements an HTTP GET /events handler (getEvents). The handler queries events from a database and, for each event, lazily loads related data (for example venue, performers, tickets, and the transactions needed for downstream processing). Perform a thorough code review and propose concrete fixes across the following areas:

Readability and architecture : Identify duplicate code, poor naming/structure, unclear responsibilities (controller mixing transport, business logic, and SQL), leaky error handling, and the absence of explicit DTOs/response shapes. Propose a layered design (controller / service / repository), centralized validation and error handling, response DTOs with field whitelisting, and structured logging with correlation IDs.
Performance : Look for N+1 queries (loading related data per event in a loop), missing pagination/limits, inefficient sorting/filtering on non-indexed columns, post-fetch in-memory filtering, missing indexes, excessive serialization/over-fetching, uncompressed payloads, and missing caching or ETags. Propose batching/joins to eliminate N+1, enforced pagination (prefer keyset/cursor), composite indexes aligned to filter+sort patterns, projections/sparse fieldsets, compression, and conditional caching (ETag/Last-Modified, Cache-Control).
Scalability : Evaluate statelessness, connection pooling, dependency fan-out and batching, timeouts/retries with jitter, circuit breakers, backpressure/load shedding, rate limiting, and asynchronous precomputation/denormalization for hot listings. Propose concrete settings and trade-offs.
Security : Verify authentication and fine-grained authorization (scope/row-level access), input validation and SQL/NoSQL injection prevention (parameterized queries, sort/include allowlists), output encoding and PII minimization, TLS requirements, CSRF/IDOR risk, least-privilege DB roles, logging redaction, and resource quotas to prevent abuse.

For each area, propose concrete fixes, explain the trade-offs, and outline correct HTTP status-code semantics. Finally, define the monitoring/alerting metrics and SLOs you would track, and a targeted test plan covering unit, integration, security (injection, authN/authZ), and performance/load tests (including a query-count budget that fails on N+1 regressions).

Question

Readability and architecture : Identify duplicate code, poor naming/structure, unclear responsibilities (controller mixing transport, business logic, and SQL), leaky error handling, and the absence of explicit DTOs/response shapes. Propose a layered design (controller / service / repository), centralized validation and error handling, response DTOs with field whitelisting, and structured logging with correlation IDs.
Performance : Look for N+1 queries (loading related data per event in a loop), missing pagination/limits, inefficient sorting/filtering on non-indexed columns, post-fetch in-memory filtering, missing indexes, excessive serialization/over-fetching, uncompressed payloads, and missing caching or ETags. Propose batching/joins to eliminate N+1, enforced pagination (prefer keyset/cursor), composite indexes aligned to filter+sort patterns, projections/sparse fieldsets, compression, and conditional caching (ETag/Last-Modified, Cache-Control).
Scalability : Evaluate statelessness, connection pooling, dependency fan-out and batching, timeouts/retries with jitter, circuit breakers, backpressure/load shedding, rate limiting, and asynchronous precomputation/denormalization for hot listings. Propose concrete settings and trade-offs.
Security : Verify authentication and fine-grained authorization (scope/row-level access), input validation and SQL/NoSQL injection prevention (parameterized queries, sort/include allowlists), output encoding and PII minimization, TLS requirements, CSRF/IDOR risk, least-privilege DB roles, logging redaction, and resource quotas to prevent abuse.

Review getEvents endpoint for readability, performance, scalability, security

Quick Overview

Question

Solution

Submit Your Answer to Earn 20XP

Review getEvents endpoint for readability, performance, scalability, security

Quick Overview

Question

Solution

Submit Your Answer to Earn 20XP