ashishps1/awesome-low-level-design

1. This repository is an educational monorepo for Low Level Design / Object-Oriented Design. It is not a single product system; it is a collection of independent examples, interview problem prompts, and reference implementations.

2. The top-level boundary is content vs. code:

• README.md explains the learning path.

• oop/ contains fundamentals of object modeling and relationships.

• design-patterns/ contains pattern-specific demos.

• problems/ contains problem statements/specs.

• solutions/ contains concrete implementations of those problems in multiple languages.

3. The code is organized by language, and each language tree is effectively its own isolated architecture:

• solutions/java, solutions/csharp, solutions/golang, solutions/python, and solutions/typescript.

• Each language folder has the same conceptual systems, but no shared runtime or cross-language dependencies.

• Build tooling varies by language: Maven for Java, .NET projects for C#, Go modules, npm/TypeScript config, and plain Python modules.

4. Inside design-patterns/, the repository is split by pattern family:

• Creational, Structural, and Behavioral patterns.

• Each pattern folder is a self-contained demo with a small entrypoint and a few collaborating classes.

• The architecture is intentionally minimal: one pattern example per directory, designed to show object relationships rather than app-scale boundaries.

5. The repeated structural pattern across examples is: domain model + orchestration object + optional extension points.

• Domain models represent the core entities, such as User, Order, Flight, Seat, Task, Message, or Player.

• Orchestrators are named like Service, System, Manager, Facade, Controller, or Demo.

• Extension points are usually interfaces or abstract bases implementing Strategy, State, Observer, Factory, Command, Decorator, etc.

6. A major architectural theme is stateful workflows. Many systems model lifecycle transitions with explicit state classes:

• Examples include vending machines, booking systems, ride-sharing trips, tasks, orders, elevator motion, traffic signals, and game states.

• The state objects own allowed transitions and behavior, while the main system/context delegates to the current state.

• This keeps invalid transitions out of the core entity and makes state diagrams central to the design.

7. Another recurring boundary is policy vs. orchestration:

• Strategy implementations handle variable business rules such as pricing, search, matching, payment, shipping, sorting, or recommendation.

• The core service/system selects a strategy and delegates the decision logic to it.

• This is visible in systems like online shopping, movie ticket booking, ride-sharing, stock brokerage, logistics, and social/feed generation examples.

8. Observer/pub-sub style flows are used for notification and side effects:

• Subjects publish domain events such as new posts, orders, auctions, trips, matches, or score changes.

• Observers handle downstream reactions like notifications, scoreboards, logs, commentary, or reputation changes.

• This creates a clean split between state mutation and reactive listeners.

9. Composite and aggregation-heavy examples model trees and collections:

• File systems, organizations, playlists, menus, or nested domain structures are represented as parent/child hierarchies.

• The composite boundary lets leaf and container objects share a common interface.

• These examples are useful for diagramming recursive ownership and uniform traversal.

10. Several examples use command/facade/adapter to hide operational complexity:

• Command appears in UI, media, stock-trading, restaurant, or device control flows.

• Facade wraps multi-step processes like deployment, restaurant management, hotel booking, or movie playback.

• Adapter appears where an external or legacy interface is normalized to an internal contract, especially in payment examples.

11. The repository is mostly in-memory and console/demo driven:

• There is no central database, service mesh, or web frontend architecture.

• Most examples instantiate objects in a demo main / Program / Demo file, execute a workflow, and print results.

• That means architecture diagrams should focus on object collaboration and runtime flow, not external infrastructure.

12. Many solution sets are duplicated across languages with the same conceptual layout:

• A single problem often exists as parallel implementations in C++, C#, Go, Java, Python, and sometimes TypeScript.

• The class names and responsibilities are usually similar across languages even when syntax differs.

• This makes the repo best understood as a pattern-and-domain catalog rather than a single integrated system.

13. A good architecture diagram for this repo should therefore emphasize:

• the educational/documentation layer,

• the per-language solution boundaries,

• and, inside each example, the interaction between entity models, orchestration/services, and pluggable pattern objects.

14. The most important architectural takeaway is that the repo demonstrates reusable design motifs, not shared application plumbing. Each folder is a standalone micro-architecture built around one problem or one design pattern.