Scalable-system design concepts for interview recall, alongside runnable distributed-systems labs covering client-server semantics, replication, consensus, and sharded transactions.
Interactive Labs
Runnable distributed-systems implementations.
sequenceDiagram
participant C as Client
participant S as Server
participant A as AMO application
participant K as Key-value store
C->>S: Request(command, client, sequence)
Note over C,S: A dropped request or reply triggers the same request again
S->>A: Execute request
alt Sequence has not executed
A->>K: Apply command
K-->>A: Result
A->>A: Cache result by client and sequence
else Duplicate sequence
A->>A: Reuse cached result
end
A-->>S: Result
S-->>C: Reply(result, sequence)
Idle
sequenceDiagram
participant C as Client
participant V as View server
participant P as Primary
participant B as Backup
C->>V: Query current view
V-->>C: View(primary, backup)
C->>P: Command
P->>B: Replicate command, including reads
Note over P,B: The primary waits for the backup before replying
alt Backup accepts the current view
B-->>P: Acknowledge
P-->>C: Result
else Backup rejects a stale primary
B-->>P: Wrong view
P-->>C: Refresh view and retry
end
sequenceDiagram
participant V as View server
participant P as Current primary
participant B as Candidate backup
participant N as Next primary
P->>V: Ping(view N)
V->>V: Mark view N acknowledged
Note over V: Only an acknowledged view may advance
alt Backup joins the acknowledged view
V-->>P: View N plus 1 with backup B
P->>B: Full application and deduplication state
B-->>P: State installed for view N plus 1
P->>V: Ping(view N plus 1)
else Primary is missed and acknowledged backup is alive
V->>V: Promote B and choose a new backup
V-->>N: New view with old primary fenced by view checks
end
Idle
sequenceDiagram
participant C as Client
participant L as Stable leader
participant Q as Quorum replicas
participant F as Lagging follower
C->>L: Command
opt Establish a new ballot
L->>Q: Prepare(ballot)
Q-->>L: Promises and accepted values
Note over L,Q: Election promises seed the first leader liveness window
Note over L,Q: Current-ballot traffic suppresses competing elections
L->>L: Adopt pmax and pending work
Note over L: Internal no-op only for ownerless interior holes
end
L->>Q: Accept(slot, command)
Q-->>L: Accepted by a quorum
L->>Q: Decision(slot, command)
L->>L: Execute decided slots in order
L-->>C: Result
sequenceDiagram
participant L as Stable leader
participant F as Follower
participant R as Replica log
loop Heartbeat and catch-up
L->>F: Heartbeat(ballot, clear-through, decisions from prior slotOut)
F->>R: Install suffix and execute contiguous decisions in order
F-->>L: Pong(next slot to execute)
L->>L: Mark follower responsive and record slotOut for next heartbeat
end
L->>L: Compute minimum slotOut reported by every replica
L->>F: Publish clear-through minimum
F->>R: Clear proposals, decisions, and accepts below watermark
Idle
flowchart TB
SM[Shard master: versioned shard ownership] -->|Query configuration| C[Client]
C -->|Route command with configuration N| G[Owning replica group]
SM -->|Publish configuration N plus 1 in order| A[Every group in configuration N or N plus 1]
A -->|Retain ConfigStart retry and reject new work| P[Replicate ConfigStart in the group log]
P --> Q{Local transactions drained?}
Q -->|No: finish or abort local transaction state| Q
Q -->|Yes: exchange replicated readiness| B{Every old-configuration group ready?}
B -->|No: retry status barrier| B
B -->|Peer already crossed this epoch: reproduce readiness| B
B -->|Yes, old owner| O[Snapshot moved shards and latest client results]
O -->|Retry transfer| N[New owner]
N -->|Import only after its local transactions drain| I[Replicated ShardImport]
I -->|Transfer acknowledgement| O
O -->|All outgoing acks| G2[Install configuration N plus 1]
I -->|All incoming shards| G2
G2 -->|Stale decided requests are discarded; clients refresh and retry| C
sequenceDiagram
participant C as Client
participant CO as Highest-ID participating coordinator group
participant P as Participant groups
C->>CO: Transaction(configuration N, stable client sequence)
CO->>CO: Replicate CoordinatorBegin(configuration N, attempt)
opt Coordinator-owned keys are busy
Note over CO: Retain Paxos-ordered wait position
CO->>CO: Retry after an ordered unlock without a new Paxos slot
end
CO->>CO: Acquire owned-key locks
CO->>P: Prepare(configuration N, transaction, attempt)
P->>P: Replicate ParticipantPrepare and lock owned keys
alt Every participant accepts in configuration N
P-->>CO: Prepared vote
CO->>CO: Replicate commit decision
CO->>P: Commit(configuration N, attempt)
P->>P: Replicate apply, result, and unlock
P-->>CO: Commit result
CO->>CO: Replicate merged result and unlock
CO-->>C: Transaction result
else Lock conflict or configuration mismatch
P-->>CO: Reject
CO->>CO: Replicate abort decision and unlock
CO->>P: Abort(configuration N, attempt) and replicate unlocks
Note over CO,P: Attempt generation fences delayed votes, replies, and timers
Note over C,CO: Retry only after abort acknowledgements drain
end
flowchart TB
M["`Inputs
Client commands · 2PC · configuration · transfer`"] --> H["`ShardStoreServer
handlers`"]
H -->|"`Wrap identity
Client: epoch + stable AMO
2PC: epoch + attempt
Reconfiguration: epoch`"| P["`Local Paxos
subnode`"]
P -->|"`Follower
Retain one retry; forward identity without allocating a slot`"| L["`Active group
leader`"]
P -->|Already leader| L
L -->|"`Assign next slot
and reach quorum`"| D["`Contiguous
decision stream`"]
D -->|Synchronous ordered callback| S{Replicated transition}
S -->|"`Client epoch command
Unwrap stable AMO`"| K["`Transactional key-value state
and client result`"]
S -->|Begin · vote · commit · abort| T["`Transaction ownership
and locks`"]
S -->|"`Config start · readiness
import · acknowledgement`"| R["`Reconfiguration
and shard state`"]
K --> O[Replies and retries]
T --> O
R --> O
Idle
Data Science
Classical machine learning experiments with reproducible AWS-backed runs, time-series-safe validation, and generated artifacts.
Interactive Labs
Runnable experiments with preserved methodology, code, and results.
Classifies low, medium, and high forward-volatility regimes from trailing OHLCV features. The label is future realized volatility, but every feature is known at the prediction date, so the model is evaluated as a regime forecast rather than a hindsight classifier.
Dataset
SPY daily OHLCV, 2010-01-04 through 2024-04-15
Label
Forward 21-day realized-volatility regime
Metric
Balanced accuracy and macro F1, so low, medium, and high regimes matter equally
Baseline
Compared against a dummy classifier; holdout balanced accuracy is above the one-third dummy baseline
Validation
Pipeline + GridSearchCV over chronological folds with a 21-row embargo; final score reported on later holdout rows
Time-series-safe classifier selection
Idle
Estimates 21-day forward return from the same trailing feature matrix. This is intentionally tested against simple baselines because noisy return prediction can look sophisticated while adding no usable signal.
Target
Forward return over a fixed horizon
Features
Trailing volatility, momentum, range, gap, and volume terms
Metric
MAE, RMSE, and directional accuracy versus zero-return, train-mean, and lagged rolling-mean baselines
Baseline
The Ridge return model is kept as a branch, but its holdout MAE does not beat the train-mean baseline
Validation
Chronological split with a 21-row embargo and fold-local imputation/scaling inside the sklearn Pipeline
Fold-local return model pipeline
Idle
Tunes the high-volatility mean-reversion branch. The branch estimates expected return from price reverting toward a trailing 21-day moving-average fair-value anchor, then applies a fixed-size signal only when the stretch clears the searched entry threshold.
Objective
Rank feasible candidates by negative Sharpe-like score plus drawdown and turnover penalties
Expected Return
21-day moving-average fair value divided by current adjusted close minus one
Parameters
Fixed low-volatility reference 0.20 and position 0.75; searched high-volatility quantile, trend filter window, and mean-reversion z-entry
Grid
48 candidates: 4 high-volatility thresholds x 3 trend windows x 4 z-entry levels
Trend Filter
Momentum acts as confirmation before taking the mean-reversion signal
Baseline
The selected rule is negative on holdout and materially trails buy-and-hold
Holdout Caveat
The selected high-volatility branch is sparse on the holdout and should be treated as a weak research baseline
Validation
Each fold fits thresholds on past rows, applies a 21-row embargo, and evaluates fair-value-driven positions on later validation rows
Chronological constrained grid objective
Idle
Combines the classifier, Ridge return model, and mean-reversion fair-value branch into one expected-price evaluation. The gate uses predicted regimes only: low predicted volatility selects Ridge expected return, high predicted volatility selects mean-reversion fair value, and medium predicted volatility stays neutral.
Gate balanced accuracy, expected-return MAE/RMSE, cumulative return, active fraction, and Sharpe-like score
Baseline
The integrated holdout result is negative and trails buy-and-hold; the high-volatility branch is sparse
Validation
Classifier and Ridge branch selected by chronological CV with a 21-row embargo; fixed mean-reversion parameters evaluated once on later holdout rows
Predicted-regime strategy gate
Idle
C++ Low Latency
C++ and Linux low-latency systems material covering hot paths, measurement, networking, shared memory, memory layout, queues, reliability, scaling, and technical discussion points. Tiers provide a progressive study path; difficulty badges describe each member's conceptual and implementation demands independently.
About
Algofolio is a DSA recall system built around:
Pattern-first categorization by reasoning technique.
Consistent variable naming, notation, and C++23 style.
Fast review through folds, filters, and multiple solution methods.