Problem statement
Design the class model and public APIs for a general-purpose logging library that application code links against (think the diagnostic logger every backend service reaches for). Code across the app asks a named logger to emit a message at some severity; the framework decides whether to record it, formats it, and writes it to one or more destinations.
Operating context. The library runs in-process inside a multi-threaded service. Many threads call the same loggers concurrently on the request path, so a log call must be cheap and safe. Loggers are named in a dotted hierarchy (for example app.payments.gateway) and each inherits an effective level and a set of destinations from its ancestors unless it overrides them. A message carries a level (TRACE, DEBUG, INFO, WARN, ERROR, FATAL), a timestamp, the origin logger name, the calling thread, and the text. A destination might be the console, a rolling file, or a network collector; the same record may fan out to several at once. Some destinations are slow, so writing must be able to hand records to a background worker instead of blocking the caller.
Out of scope. The on-disk file-rotation and retention mechanics, the wire protocol to any remote collector, log parsing/search/query, distributed log aggregation across hosts, and reading configuration from a file or environment (assume config is supplied programmatically). Focus on the in-process object model, not I/O internals.
What to produce. The class hierarchy (the logger, the logger registry/factory, the level type, the record, the destination/sink abstraction, the message formatter, and the async dispatch seam), the public API each type exposes, and the lifecycle of a single log call from the call site to the bytes leaving a sink. Be explicit about: how a logger's effective level and destination set resolve through the name hierarchy; how a record fans out to a chain of sinks each with its own level and formatter; how formatting is pluggable without touching sink code; how the synchronous fast path and the asynchronous buffered path differ and how the buffer behaves when it fills; and how concurrent log calls, live config changes, and shutdown stay thread-safe without serializing every caller.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design LLD
- Oop Solid
- Patterns Strategy
- Concurrency Threadpool
- Extensibility