The skill track
The course follows the same stack: core Java, commerce platform, headless front end, distributed systems and agents.
Track 01
The full interview path: the framework, core concepts, networking, data, caching, messaging, coordination, production, performance, security, technologies and twelve worked practice problems.
What the round is, the six moves that carry any design, the arithmetic you do out loud, and the mistakes that end interviews early.
It is a design review with a stranger, on a clock, scored on four signals.
Clarify, estimate, contract, design, deepen, close. Same order for every prompt.
Four numbers, rounded hard, said out loud with the decision attached.
The dozen figures that let you size a system without hesitating.
Ten ways strong candidates fail, the fix for each, and how to recover mid-round.
The vocabulary every design round runs on: scaling, latency, reliability, availability, failure, consistency and the principles that tie them together.
Growth is the default state. Scalability is whether your design survives it.
Three numbers that get confused constantly. Percentiles are the only honest latency.
Write down what 'working' means, measure it, then decide how much failure you can afford.
Each nine costs roughly ten times as much as the one before it.
One question finds them all: what happens if this dies right now?
A spare that nobody promotes is just a second copy of the problem.
Assume the parts break. Design what the user still gets.
Partitions are not optional. The real question is what you give up, and only while they last.
Adding a cache node should not invalidate almost everything.
The defaults that make a design defensible when the interviewer pushes.
What happens between a tap and a response: DNS, TCP, TLS, HTTP, balancing, and the three API styles you will be asked to choose between.
From a tap on a phone to a row in a database and back, in about 200 milliseconds.
Most designs need a request and a reply. Some need the server to speak first.
Caching headers, timeouts, retries, and encryption: the unglamorous parts that decide whether a system stays up.
Four algorithms, two layers, one question: what happens when a backend dies mid-request?
The right API style follows from who calls it and how often the contract changes.
Rate limits, quotas, backpressure, and graceful degradation — the difference between a spike and an outage.
Choosing and defending a datastore: relational versus document versus wide-column, indexes, isolation levels, replication, sharding, and when a search engine belongs in the design.
Ask about access patterns, then about consistency, then pick a family — the product name is the last decision.
A query without an index is a full scan, and a full scan is a latency cliff.
ACID is a promise with a dial. Know which dial position your workload needs.
The replica is not a backup, and the seconds it lags are where stale data bites.
Partitioning buys scale and takes away joins, uniqueness, and easy rebalancing.
Two systems that are never the source of truth, and how to keep them from drifting.
Where a cache earns its keep, the three strategies worth knowing, how invalidation actually works, and what a CDN changes about a design.
A cache is a bet that the same data will be asked for twice, soon, and can be slightly stale.
Cache-aside is the default; write-through, write-behind, read-through and refresh-ahead exist for specific shapes.
The hard part of caching is not storing the answer. It is knowing when the answer changed.
Most bytes a service sends are static, identical for every user, and never change.
Queues versus logs, delivery guarantees, ordering, backpressure, and the event-driven patterns that decouple services without hiding failures.
A queue deletes a message when it is done; a log keeps it and lets readers move a bookmark.
At-most-once, at-least-once, and exactly-once — only two of these exist on a network you don't control.
An asynchronous system does not remove load, it stores it. The queue depth is the bill.
Events are a decoupling tool and a debugging tax. Use three patterns, not thirteen.
How independent machines agree on one truth: consensus and quorums, leases and locks, and the uncomfortable reality of clocks and ordering.
Getting five machines to agree is not five times harder than one. It is a different kind of problem.
A lock without an expiry is a permanent outage waiting for a single crash.
Two machines with the same wall clock will disagree by more than you think.
What keeps a design alive after launch: resilience patterns, observability that answers questions, scaling a fleet without manual surgery, and shipping changes safely.
Most outages are a slow dependency plus unlimited patience.
Dashboards are not observability. Being able to answer "why is checkout slow right now?" is.
The interesting part is not adding servers. It is what breaks when the number of servers changes.
Schema migrations are the part of deployment that cannot be rolled back by redeploying.
The "why is it slow?" playbook: measuring before guessing, reading tails instead of averages, and the recurring mistakes that turn small inefficiencies into capacity bills.
Measure the layer, then the hop, then the line of code. Guessing wastes the incident.
None of these are bugs. All of them multiply traffic, latency or storage until the bill arrives.
Who is calling, what may they touch, and what happens if the data leaks: identity and authorisation, protecting data in transit and at rest, and defending the public edge.
Login is a solved problem. Deciding what a logged-in user may touch is the design work.
Encryption is not a checkbox; it is a decision about who holds the key.
Every public endpoint will be called by something you did not design for.
The map of real systems: which category each tool belongs to, what it is good at, and the handful of patterns that keep reappearing across every design.
Interviewers remember the reason you chose a category, not the vendor you named.
Most design problems are one of a dozen shapes wearing a product name.
Twelve designs worked end to end with the six-move framework: requirements, estimates, API, data model, high-level design, deep dives and bottlenecks.
The warm-up problem. Small surface area, one interesting property: reads outnumber writes by a hundred to one.
A counter that must be shared, atomic, and fast — and must still work when the counter store is down.
Ten keystrokes, ten queries, and a 100 ms budget. Precompute almost everything.
A polite, deduplicating pipeline that has to decide what to fetch, how often, and when to stop.
The classic fan-out trade-off, plus the part people forget: ranking and caching the result.
Durable connections, ordered messages per conversation, and delivery that survives a phone going offline.
Multi-channel delivery where the hard parts are preferences, deduplication and not waking someone twice.
Find nearby drivers, pick one, and never assign the same driver twice.
Upload is a pipeline; playback is a caching problem. Treat them as two systems.
Metadata consistency is the hard part; the bytes are just blobs in a bucket.
An inverted index, a relevance function, and filters that must stay fast as the catalogue grows.
The problem where correctness beats availability, and every rule is about failure.
I'll get back to you as soon as I can, usually within a day.
Check yourself
Instant feedback with explanations, so a wrong answer teaches the concept.
AI tutor
Concepts, numbers, trade-offs and problem walkthroughs — in plain language.
Simulator
Load a blueprint, push traffic through it and inject failures — the metrics show what gives way first.
Begin with the interview framework, then work module by module. Every lesson ends with a checkpoint.