Audit Logs Service

Design an audit-log service where users can query audit events for their own account. The round focuses on transaction-log storage, scaling the write and query paths, and keeping account-scoped queries low latency. Requirements Users can query audit logs that belong to their own account. Audit events are generated from account activity and must be retained as an append-style transaction log. Query path must support low latency for account-scoped lookups. Design the storage model for transaction logs and query indexes. Discuss how the service scales as log volume and account count grow. Authorization is part of the read path: a user must not be able to query another account's audit log. Notes A clean design separates the write-optimized transaction log from the read-optimized account/time index. The source of truth can be append-only, while query serving uses partitioned indexes by account and timestamp. Sharding by account keeps most user queries single-shard and makes authorization checks local to the request context. The trade-off is handling very large accounts whose logs dominate a shard. Low latency depends on bounding query ranges: require account ID plus time range / pagination token, and avoid unbounded scans over the full log. Retention and compliance should be explicit. Audit logs usually need immutable storage, deletion policy discussion, and tamper-evident metadata even if the interviewer does not ask first. Deep dives to prepare: hot-account sharding, backfill / replay from the append log, index lag, and whether query results must be strongly consistent with just-written events. Preparation Sketch the write path: application event -> durable log -> async indexer -> account/time query store. Prepare a schema for (account_id, event_time, actor_id, action, resource, metadata) and explain which fields are indexed. Walk through one hot-account mitigation, such as splitting by (account_id, time_bucket) or adding virtual shards for large tenants.