algomiBlogs
← All posts

Low-Level Design Foundations: OOP, SOLID, and Design Patterns in Java, Told Through a Tea Shop

Algomi Research · Created 2026-09-29 · Updated 2026-10-15 · System Design

Interview Roadmap Deep Dives · Part 19 of 28
Production Engineering: Observability, Security, Deployment, Kubernetes, and CostConcurrency and Multithreading in Java for LLD: Races, Locks, and Producer-Consumer
Page 1 of 1

Meet Chai Corner

Imagine a tiny tea shop called Chai Corner (a made-up shop, used only to teach). One cashier takes orders. One barista makes the drinks. A little bell rings when a drink is ready. Customers can add milk or sugar, use a coupon, and get a message when their order is done.

That whole shop is a low-level design (LLD). High-level design decides which shops exist and how they talk to each other. LLD decides what happens inside one shop: who does which job, and how the shop can change (a new coupon, a new payment machine) without being rebuilt from scratch.

We will use Chai Corner for every idea in this post. First we explain it like you are five (ELI5: "explain like I'm five"), then give the precise technical meaning, then show a short piece of Java. The code uses Java 17 features such as record, and every snippet was compiled and run.

The next posts apply these ideas: concurrency, then two sets of machine-coding case studies.

1. The four OOP ideas, in the tea shop

Idea Chai Corner (ELI5) Technical meaning Interview trap
Encapsulation The cash drawer is behind the counter. You hand money to the cashier; you do not reach in. Keep state private; expose behaviour Public mutable fields everywhere
Abstraction You say "one tea, please". You do not need to know how the stove works. Depend on a simple interface, hide detail Leaky interfaces that expose storage choices
Inheritance A "Masala Tea" is a kind of tea, so it starts with the normal tea recipe. A subtype reuses and specialises a parent Deep hierarchies used just for code reuse
Polymorphism Say "serve it" to any drink. Tea is poured; a cold coffee is shaken. Same words, different action. Same call, different behaviour by type Long instanceof or switch chains on type

Prefer composition over inheritance: build behaviour by holding collaborators ("has a") instead of extending classes ("is a") (overview). In the shop: the cashier has a card machine. The cashier is not a kind of card machine. If the shop changes machines, the cashier does not change. Inheritance couples child to parent; composition lets you swap parts at runtime.

You've reached the free preview of this post.

Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.

See plans

Sources

Interview Roadmap Deep Dives · Part 19 of 28
Production Engineering: Observability, Security, Deployment, Kubernetes, and CostConcurrency and Multithreading in Java for LLD: Races, Locks, and Producer-Consumer