Modern Application Paradigms
This page makes five current engineering paradigms explicit in the degree plan. The curriculum already teaches many prerequisites: events, memory hierarchy, distributed systems, testing, architecture, and operations. This track names the modern application patterns that sit on top of those foundations.
The goal is not trend-chasing. The goal is that by the capstone, the learner can recognize when these paradigms are useful, explain the tradeoffs, and build a small production-shaped example.
Coverage Map
| Paradigm | Current foundation in the plan | New expectation |
|---|---|---|
| Reactive programming | Observer, pub-sub, event-driven architecture, backpressure, streams | Model UI/application state as dependency graphs and event streams, not only callbacks or CRUD handlers |
| Edge computing patterns | CDN/cache placement, cloud deployment, latency reasoning, system design | Decide what logic belongs at edge, origin, client, or background worker; account for runtime limits |
| Data-oriented design | C structs, memory hierarchy, cache-aware programming, AoS vs SoA, benchmarks | Treat data layout and access pattern as design decisions, not only performance afterthoughts |
| LLM application architecture | Build-your-own LLM, RAG extension, AI supervision policy, capstone AI integration | Build reliable LLM features with retrieval, evaluation, prompt/version tracking, guardrails, observability, and fallback behavior |
| Local-first software | Replication, consistency models, CRDT references, offline availability examples | Design offline-capable apps where local state is useful independently and sync is an explicit subsystem |
1. Reactive Programming
Reactive programming is the habit of modeling changing values and event streams directly. The important idea is not that a framework has an Observable or signal API. The important idea is that derived state updates because the dependency relationship is declared.
What To Learn
- signals, observables, event streams, and derived state
- push vs pull, cold vs hot streams, backpressure, cancellation, and subscription lifetime
- UI state as a graph of dependencies
- frontend reactivity failure modes: stale derived state, accidental resubscription, memory leaks, and update ordering bugs
Where It Fits
| Semester | Integration |
|---|---|
| 3 | Extend Observer/pub-sub design patterns into reactive dependency graphs |
| 7-8 | Connect event-driven architecture, projections, and backpressure to stream thinking |
| 10 | Optional capstone: real-time dashboard, collaborative UI, or streaming workflow |
Required Artifact
Build a small reactive UI or service pipeline with:
- at least three independent event sources
- at least two derived values
- explicit cleanup/cancellation behavior
- a written note explaining dataflow and failure modes
Recommended sources:
- SolidJS docs, "Intro to reactivity": https://docs.solidjs.com/concepts/intro-to-reactivity
- Angular Signals discussion: https://github.com/angular/angular/discussions/49090
- RxJS docs: https://rxjs.dev/guide/overview
2. Edge Computing Patterns
Edge computing changes the placement question. Some code belongs near the user, some near the database, some in the browser, and some in background jobs. The edge is useful when it reduces latency or origin load without violating consistency, security, or runtime constraints.
What To Learn
- edge runtime constraints: Web APIs, limited CPU/runtime assumptions, no full Node.js surface in many environments
- cache keys, cache invalidation, request coalescing, stale-while-revalidate, and origin shielding
- partial personalization: personalize the shell or routing decision without making the whole response uncacheable
- auth and policy at the edge: JWT verification, redirects, rate limits, bot controls
- split placement: client, edge, origin API, database, queue, background worker
Where It Fits
| Semester | Integration |
|---|---|
| 8 | Add edge placement to system-design tradeoff exercises |
| 9 | Add an optional Cloudflare Workers, Vercel Edge, or Deno Deploy deployment lane |
| 10 | Optional capstone: edge-auth gateway, global read cache, or edge-personalized landing/API shell |
Required Artifact
Create an edge placement ADR for one project:
- what runs at the edge
- what must stay at origin
- what is cached and for how long
- how personalization changes cacheability
- what runtime limitation affects the design
Recommended sources:
- Cloudflare Workers docs: https://developers.cloudflare.com/workers/
- Vercel Edge Functions docs: https://vercel.com/docs/functions/runtimes/edge
- Deno Deploy docs: https://docs.deno.com/deploy/
- tRPC Fetch/Edge runtimes adapter: https://trpc.io/docs/server/adapters/fetch
3. Data-Oriented Design
Data-oriented design asks what data exists, how often it is touched, and how it moves through memory. It is not just "make it faster." It often makes the code simpler because the program structure follows the data transformation instead of a hierarchy of objects.
What To Learn
- access patterns before abstractions
- array of structs vs struct of arrays
- hot/cold data separation
- cache lines, locality, branch prediction, memory bandwidth, and allocation behavior
- batch processing and columnar thinking
- when object-oriented modeling is useful and when it fights the workload
Where It Fits
| Semester | Integration |
|---|---|
| 2 | Compare algorithm choices using realistic memory layout and benchmarks |
| 4 | Extend C struct/layout work into explicit data-layout decisions |
| 5-6 | Apply locality thinking to OS, storage engines, indexing, and query execution |
| 10 | Optional capstone: performance-sensitive service, renderer, search/indexing component, or telemetry pipeline |
Required Artifact
Benchmark one implementation written in an object/record-oriented style against one written in a data-oriented style:
- define the workload
- measure wall time and memory behavior
- explain AoS vs SoA or equivalent layout choice
- state when the data-oriented version is not worth the complexity
Recommended sources:
- Data-Oriented Design site: https://www.dataorienteddesign.com/site.php
- Sebastian Schoner, "Data Oriented Design - An Interpretation": https://blog.s-schoener.com/2019-06-09-data-oriented-design/
- James McMurray, "An introduction to Data Oriented Design with Rust": https://jamesmcm.github.io/blog/intro-dod/
4. LLM Application Architecture
Building with LLMs is not the same as calling an LLM API. Production LLM features need retrieval, context management, evaluations, observability, cost controls, and fallback behavior.
What To Learn
- RAG pipeline: ingestion, chunking, embeddings, retrieval, reranking, synthesis, citations
- prompt and model versioning
- evaluation sets, regression tests, retrieval quality metrics, and human review
- context-window budgeting and summarization/compaction strategies
- agent orchestration only when the task truly needs planning/tool use
- privacy, retention, cost, latency, safety, and fallback behavior
Where It Fits
| Semester | Integration |
|---|---|
| 2-4 | Build-your-own neural network/LLM path for fundamentals |
| 6-7 | Connect RAG to search engines, databases, APIs, and architecture decisions |
| 8-9 | Add evals, observability, cost controls, and reliability gates |
| 10 | Optional capstone: production-shaped LLM assistant with evaluation evidence |
Required Artifact
For any LLM-backed feature, include:
- architecture diagram for retrieval/context/tool flow
- prompt/model version log
- evaluation dataset with pass/fail criteria
- failure-mode tests
- cost and latency estimate
- privacy/data-retention note
- fallback and human-review policy
Recommended sources:
- LlamaIndex RAG documentation: https://developers.llamaindex.ai/python/framework/understanding/rag/
- LangSmith RAG evaluation tutorial: https://docs.langchain.com/langsmith/evaluate-rag-tutorial
- OpenAI prompt engineering guide: https://platform.openai.com/docs/guides/prompt-engineering
- Arize Phoenix: https://github.com/Arize-ai/phoenix
5. Local-First Software
Local-first software treats the local device as a real runtime and data store, not merely a thin client. The application remains useful offline, and synchronization becomes an explicit system with failure modes.
What To Learn
- offline-first UX and local durability
- sync engines, conflict detection, conflict resolution, and merge semantics
- CRDTs, operational transformation, vector clocks, and causal ordering
- browser/local databases, including SQLite/WASM options
- server as coordinator, backup, collaboration peer, or authority depending on domain
- security and data-ownership implications of local copies
Where It Fits
| Semester | Integration |
|---|---|
| 6 | Tie CRDTs, replication, clocks, and consistency models to user-visible sync |
| 7-8 | Include offline and sync behavior in architecture tradeoff exercises |
| 9 | Allow local-first production-shaped deployment lane without paid cloud |
| 10 | Optional capstone: offline-capable inventory, notes, field-work, or collaboration system |
Required Artifact
Design and implement a small offline-capable feature:
- local persistence
- offline create/update flow
- sync after reconnect
- one conflict scenario
- user-visible sync state
- written consistency contract
Recommended sources:
- Ink & Switch, "Local-first software": https://www.inkandswitch.com/essay/local-first/
- Local-first paper PDF: https://martin.kleppmann.com/papers/local-first.pdf
- Automerge docs: https://automerge.org/docs/hello/
- ElectricSQL docs: https://electric-sql.com/docs
- SQLite WASM docs: https://sqlite.org/wasm/doc/trunk/index.md
Capstone Expectation
The capstone does not need to use all five paradigms. It must explicitly address at least one:
- reactive state/dataflow
- edge placement
- data-oriented performance design
- LLM application architecture
- local-first/offline sync
The chosen paradigm should appear in the capstone ADRs, tests, and final defense. If the paradigm is rejected, the rejection should be defended with concrete constraints.