Loading low-level design…

Design a Logging Framework - Low-Level Design | OneNoughtOne

00:00:00

Design a Logging Framework

Beginner

Design an object-oriented logging framework that supports multiple log levels (DEBUG, INFO, WARNING, ERROR, FATAL), writes to pluggable sinks (console, file, database), and exposes a singleton API for application-wide access.

The framework should filter messages by a configurable minimum level, format output with timestamps and source info, and be extensible for new sinks without modifying existing code.

Core Use Cases

Log messages at different levels

Support DEBUG, INFO, WARNING, ERROR, and FATAL log levels

Filter by log level

Only process messages at or above the configured minimum level

Write to multiple sinks

Fan-out each log message to console, file, database, or custom sinks simultaneously

Format log output

Produce structured log strings with timestamp, level, source, and message

Global logger access

Provide a single shared logger instance across the application via Singleton

Configure at runtime

Add/remove sinks and change log level without restarting the application

Constraints

Logger must be a singleton — only one instance across the application
Log level filtering must happen before sink dispatch (avoid unnecessary work)
Sinks must be independent — one sink failing must not affect others
Thread-safe logging in multi-threaded environments
Log messages must include timestamp, level, source, and message body

Assumptions

Log messages are plain text (no structured/JSON logging initially)
File sink appends to a single log file (no rotation)
Timestamps use system local time
Source is an optional caller-provided string (e.g., class or module name)

In Scope

Singleton logger with level-based filtering
Multiple sink support (console, file, database)
Formatted log message output
Runtime configuration of sinks and levels

Out of Scope

Log file rotation and archival
Structured JSON logging
Remote log aggregation (e.g., ELK, Splunk)
Asynchronous / buffered logging
Log sampling or rate limiting

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Loading LLD design...

00:00:00

Design a Logging Framework

Beginner

The framework should filter messages by a configurable minimum level, format output with timestamps and source info, and be extensible for new sinks without modifying existing code.

Core Use Cases

Log messages at different levels

Support DEBUG, INFO, WARNING, ERROR, and FATAL log levels

Filter by log level

Only process messages at or above the configured minimum level

Write to multiple sinks

Fan-out each log message to console, file, database, or custom sinks simultaneously

Format log output

Produce structured log strings with timestamp, level, source, and message

Global logger access

Provide a single shared logger instance across the application via Singleton

Configure at runtime

Add/remove sinks and change log level without restarting the application

Constraints

Logger must be a singleton — only one instance across the application
Log level filtering must happen before sink dispatch (avoid unnecessary work)
Sinks must be independent — one sink failing must not affect others
Thread-safe logging in multi-threaded environments
Log messages must include timestamp, level, source, and message body

Assumptions

Log messages are plain text (no structured/JSON logging initially)
File sink appends to a single log file (no rotation)
Timestamps use system local time
Source is an optional caller-provided string (e.g., class or module name)

In Scope

Singleton logger with level-based filtering
Multiple sink support (console, file, database)
Formatted log message output
Runtime configuration of sinks and levels

Out of Scope

Log file rotation and archival
Structured JSON logging
Remote log aggregation (e.g., ELK, Splunk)
Asynchronous / buffered logging
Log sampling or rate limiting

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Design a Logging Framework

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design a Logging Framework

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design a Logging Framework

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you add log file rotation (e.g., rotate at 10 MB)?

2How would you make logging asynchronous to avoid blocking the caller?

3How would you add structured JSON logging alongside plain text?

4How would you support per-module log levels (e.g., DEBUG for auth, ERROR for db)?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions

Design a Logging Framework

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you add log file rotation (e.g., rotate at 10 MB)?

2How would you make logging asynchronous to avoid blocking the caller?

3How would you add structured JSON logging alongside plain text?

4How would you support per-module log levels (e.g., DEBUG for auth, ERROR for db)?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions