Future Proof India · Software Architecture Workshop

Interactive Architecture Labs

Don't just hear the concepts — see them move. Click a lab, press the button, and watch monoliths, microservices, queues and events behave in real time.

A hands-on lab for every day of the workshop.

D1

Day 1

Microservices, Event-Driven & Agentic Architecture
17 labs

Event-Driven

7

Topology vs Communication

Monolith-or-microservices and synchronous-or-asynchronous are NOT the same question. Click each cell of the 2×2 and see why a monolith can be async and microservices can be sync.

Topology vs communication are orthogonalOpen →
8

Synchronous vs Asynchronous

Place an order. Sync makes the user wait through a 4-second chain. Async confirms in 200ms and drains work in the background.

Sync request/response vs async messagingOpen →
9

Queue vs Topic (Pub/Sub)

Emit OrderPlaced. In a queue one worker grabs it; in a topic it fans out to everyone. Add a WhatsApp subscriber live.

Competing consumers vs fan-outOpen →
10

Life of a Message — Queue vs Pub/Sub vs Stream

Drop the same event into all three and watch what's left afterward: a queue deletes it, pub/sub forgets offline subscribers, and a stream keeps it on a replayable log with offsets and consumer groups.

Message retention, offsets & replayOpen →
11

Failure, Retry & Dead Letter Queue

Kill the Email service. Watch retries with backoff, messages land in the DLQ, the order stays green — then replay the DLQ.

Retry, backoff, DLQ, idempotencyOpen →
12

Event-Driven System — Watch It Live

Fire an OrderPlaced event and watch it flow producer → broker → many consumers (Inventory, Email, Analytics, Fraud) reacting at once. Add or kill a consumer live, slow one to watch its backlog build, and switch a queue to a topic — the whole system breathing on one canvas.

End-to-end event flow: produce → route → consumeOpen →
13

The Saga Pattern — Orchestration, Choreography & Rollback

Run a multi-step Order saga across services that share no database: Reserve Inventory → Charge Payment → Arrange Shipping → Confirm. Coordinate it with a central orchestrator or with pure choreography — then fail a step and watch compensating transactions roll the whole thing back in reverse.

Distributed transactions: saga orchestration vs choreography + compensationOpen →

Agentic AI

14

Agent Architecture — Microservices vs Monolith

Run the same multi-agent system two ways: each agent as its own API orchestrated by LangGraph, vs one LangGraph monolith in a single codebase. Compare latency, deploys, scaling and failure isolation.

Microservices for multi-agent systems (the WHERE axis)Open →
15

Backpressure — Why a Broker Absorbs Spikes

Push traffic past capacity with no broker and watch the waiting room overflow and drop requests. Add a broker and the same spike is buffered safely — nothing lost — then add a consumer to drain it.

A broker decouples producers from consumers (the HOW axis)Open →
16

Where Does LangGraph Fit? — Orchestration vs Choreography

Run the same agent pipeline three ways. A LangGraph conductor that holds state and decides order; pure event choreography with no conductor; and the hybrid real systems actually ship — events between services, LangGraph orchestrating the reasoning inside one. See why event-driven doesn't delete the orchestrator, it relocates it.

Control flow: orchestration vs choreography (the WHO axis)Open →
17

Agent Orchestration — LangGraph vs Message Broker

The same research-assistant workflow — plan, three parallel researchers, synthesize, critique, loop back if rejected — run two ways. As a LangGraph state machine with a shared state object and a loop-back edge, and as event-driven agents coordinated through a broker. Watch both execute and weigh control, state, resilience and scale.

Orchestrating multi-agent workflows: in-process graph vs event brokerOpen →
D2

Day 2

Scaling Applications & Databases
14 labs

Database Scaling

23

Index vs Full Table Scan

Run a query with no index and watch the scanner sweep every row; add an index and it jumps straight to the answer. Grow the table and the scan explodes while the index stays flat.

Indexes & composite indexes vs full scansOpen →
24

Connection Pooling — When App Scaling Floods the DB

Scale the app to 50 instances and each opens its own database connections — the DB blows past its connection limit and rejects everyone. Add a pool and a few hundred shared connections serve every instance.

Connection pooling vs connection exhaustionOpen →
25

Read Replicas & Read/Write Split

ChatSphere's feed is read-heavy. One DB chokes; add replicas and reads fan out while the primary takes writes. Then meet the trade-off: replica lag serving a stale read.

Read/write split, replicas & replica lagOpen →
26

Partitioning vs Sharding — Same Rows, Different Homes

The Day-2 head-scratcher, settled. Split one table into row-ranges inside a single database (partitioning), or distribute those same rows across separate servers with a shard key (sharding). Toggle between them on identical data — and see why it's always rows, never columns, and how you can do both at once.

Partitioning (within a node) vs sharding (across nodes)Open →
27

Sharding & the Shard Key

Split data across DB servers by shard key and watch writes distribute. Then break it: a bad key melts one hot shard while others idle, and a cross-shard join turns ugly.

Horizontal data partitioning & shard-key choiceOpen →
28

Strong vs Eventual Consistency

A payment balance needs the latest truth; a feed like-count can lag a moment. Toggle between strong and eventual consistency and watch freshness trade against speed and availability.

Strong vs eventual consistency trade-offsOpen →
29

Cache the Hot Path

Every feed request hammers the DB. Put a cache in front and watch the hit-ratio climb and DB load collapse — then feel the catch when stale data is served until the cache expires.

Caching, hit ratio & invalidation/stalenessOpen →
D3

Day 3

Fault Tolerance, Resilience, Caching & CDN
13 labs

Resilience Patterns

32

Graceful Degradation — The Resilient Search

BookZilla queries Flight, Train and Bus providers. Set each to healthy, slow or down. A naive page hangs on the slow one and breaks on the down one; a resilient page uses a 2s timeout, fails fast to a fallback, and still shows the providers that work — marking the rest temporarily unavailable.

Timeout, fail-fast, fallback & partial resultsOpen →
33

Retry, Backoff & Idempotency

Retry a flaky call and watch a naive retry storm pile onto a recovering service. Switch on exponential backoff, then add jitter to de-sync the herd — and see why you must NOT retry a declined card. Then an idempotency key stops a retried charge from billing twice.

Backoff, jitter, when-not-to-retry & idempotency keysOpen →
34

Circuit Breaker — Closed, Open & Half-Open

A failing provider, a live request stream, and the breaker's state machine. Without it, every call waits the full timeout then fails. With it, repeated failures trip the breaker OPEN (calls fast-fail to fallback), a cooldown ticks, then HALF-OPEN probes decide whether to close again. Watch the states flip in real time.

The circuit-breaker state machine & fast-failOpen →
35

Cascading Failure & Bulkheads

One shared thread pool serves all three providers. Make Flight slow and watch blocked requests fill the pool until Train and Bus starve — a cascading failure. Flip on bulkheads (a pool per provider) and the flight failure stays contained while everything else keeps flowing.

Resource isolation stops one failure sinking the systemOpen →
36

Redundancy & Failover

Run primary + backup as active-passive or active-active, with health checks watching the primary. Kill the primary and watch traffic fail over to the backup — with the real brief blip in between — then compare the two redundancy modes on cost and recovery.

Redundancy, health checks & automatic failoverOpen →
D4

Day 4

Security, Cloud Security & Observability
19 labs

Secure Architecture

45

Broken Access Control (IDOR)

The exact healthcare breach: logged in as one patient, change the record id in the URL. Without a server-side ownership check you read someone else's report; with it you get 403. Login is not authorization.

Broken access control & ownership checksOpen →
46

Role-Based Access Control — Permission Matrix

Pick a role — patient, doctor, insurer, admin — and try actions like viewing others' reports or managing users. Watch a live allow/deny matrix decide each one. Each role gets only what it needs.

RBAC roles, permissions & least privilegeOpen →
47

JWT — Decoded & Tampered

A real header.payload.signature token, decoded into its claims. Edit role from patient to admin and the signature check fails; let it expire and it's rejected. See exactly why a JWT must be validated, not trusted.

Token claims, signatures & validationOpen →
48

SQL Injection — Live

Type ' OR 1=1 -- into a login box. A string-built query hands the attacker every row; a parameterized query treats it as harmless text. Watch the actual SQL the database receives in both cases.

Injection & parameterized queriesOpen →
49

STRIDE Threat Model

Walk the appointment system through STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege. Click each threat to see how it attacks the system and the mitigation that stops it.

Structured threat modeling with STRIDEOpen →
50

Least Privilege & Blast Radius

A credential leaks. With an over-permissive role the attacker's reach spreads across every resource; with least privilege the damage is contained to one box. Smaller privilege, smaller blast radius.

Least privilege limits the blast radiusOpen →
51

Defense in Depth

An attacker tries to reach patient data through layers — WAF, gateway auth, service authorization, network isolation, DB permissions, encryption. Toggle layers on and off and watch how far the attack gets when one fails.

Layered defense & fail-safe defaultsOpen →
62

Authentication vs Authorization vs RBAC

Three words people blur together, separated cleanly. Send a request through two gates — Authentication (who are you?) then Authorization (are you allowed?) — and see RBAC as the mechanism that decides the second. Watch a valid login still get denied the wrong action.

AuthN (who) vs AuthZ (what) vs RBAC (how it's decided)Open →
63

OWASP Top 10 (2025) — Explorer

All ten of the 2025 OWASP risks in one place. Click any category to see what it is, a concrete healthcare-platform example, and the mitigation — with badges for what's new, moved or renamed since 2021, and links to the hands-on lab for each.

The 2025 OWASP Top 10, mapped to real fixesOpen →

Observability

55

Three Pillars — One Incident, Three Lenses

A booking request is slow. See the same incident through a metric (latency spiked), then logs (booking errors), then a trace (an 8s payment span). Why you need metrics, logs AND traces — and how they hand off.

Metrics, logs & traces togetherOpen →
56

Latency Percentiles — p50 / p95 / p99

A live latency distribution. The average says 300ms and looks fine — but the p99 marker sits at 8s because of a slow tail. Add a few slow requests and watch the average barely move while p99 explodes.

Why averages hide tail latencyOpen →
57

Structured Logging & Correlation IDs

Plain logs from five services interleave into noise — impossible to follow one request. Switch on structured logs with a shared trace id, filter to one id, and the request's whole journey across services reconstructs itself.

Structured logs & correlation across servicesOpen →
58

Distributed Tracing — The Waterfall

A slow request crosses API Gateway → Auth → Appointment → Payment → Notification. Render the span waterfall and spot the culprit instantly. Inject latency into any service and watch the waterfall shift to point at it.

Spans, trace waterfalls & finding the slow serviceOpen →
59

Alerting & Alert Fatigue

Tune threshold, duration and impact. A bare 'CPU > 80%' fires constantly and gets ignored; an SLO-style 'booking errors > 5% for 5 min affecting >100 users' fires only on real incidents. Watch false alarms trade off against missed incidents.

Actionable alerts vs alert fatigueOpen →
D5

Day 5

Capstone — Architecture on an AI Agent
1 labs