SQL or NoSQL for high-volume semi-structured event ingestion?

WHAT THIS TESTS: This question probes your ability to match storage technology to data shape and access patterns. The interviewer wants to see that you distinguish between a high-velocity, schema-flexible ingestion layer and a structured analytics layer. They are looking for pragmatism over dogma: can you justify why rigid schemas and ACID guarantees are often liabilities for raw event firehoses?

A GOOD ANSWER COVERS: First, pick NoSQL for the landing zone and justify it with three specific traits: schema flexibility because mobile app events add new fields without warning; horizontal scalability to absorb millions of writes per second across many nodes; and low-latency ingestion because the pipeline should not block on complex transactions. Second, name a concrete NoSQL variant, such as a document store like MongoDB or DynamoDB, or a wide-column store like Cassandra, explaining that JSON-like or key-value shapes map naturally to semi-structured click payloads. Third, explicitly state that SQL is not wrong forever; it belongs downstream after cleaning and schema enforcement, where relational algebra, joins, and strong consistency become valuable. Fourth, mention cost and operational realities: sharding a relational database for pure write throughput is harder than scaling out a NoSQL cluster.

COMMON WRONG ANSWERS: The biggest red flag is choosing SQL for the raw landing zone and defending it with generic ACID arguments. Event logs are typically append-only and immutable; they do not need multi-row transactions or strict relational integrity at ingestion time. Another red flag is treating NoSQL as a magic word without explaining which type fits: saying NoSQL without distinguishing between document, key-value, or columnar stores shows shallow knowledge. A third mistake is ignoring the two-tier architecture entirely and insisting one database must handle both ingestion and analytics.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle late-arriving events or schema evolution. They might probe how you guarantee at-least-once delivery before the landing zone. They could also ask for a concrete comparison of DynamoDB versus Cassandra for this use case, or how you would migrate from the NoSQL landing zone to a relational data warehouse.

ONE CONCRETE EXAMPLE: Imagine a mobile game sending JSON click events with fields like timestamp, user_id, event_type, and a nested properties bag. On launch day the app adds a new field called ab_test_variant. A document database ingests the new field immediately with no migration. A relational database would require an ALTER TABLE command that locks millions of rows and breaks the ingestion pipeline. After twenty-four hours a batch job normalizes the most common fields into a PostgreSQL warehouse for cohort analysis, leaving the raw JSON in cold storage for replay.

Source: aws.amazon.com