▸ System Design Master Reference

SYSTEM DESIGN INTELLIGENCE FOR FBT

Every concept, pattern, and principle from the DesignGurus System Design Interview curriculum — extracted, analysed, and mapped 1:1 to FBT's current and future engineering challenges. This is your architecture decision Bible.

95+Concepts

18System Designs

15Patterns

4Projects

∞Scale

NOWApply

📋

System Design Foundations

MODULE 01 · 12 core concepts

The bedrock of every system design decision. DesignGurus opens with these because everything else builds on them — scalability, reliability, availability, and the trade-offs between them.

📐

Scalability

FOUNDATIONS

Vertical scaling (bigger machines) vs Horizontal scaling (more machines). Vertical has a ceiling; horizontal requires stateless design. Scale-cube model: X-axis (clone), Y-axis (decompose), Z-axis (partition).

FBT APPLICATION
RentFlow must scale horizontally — multi-tenant means unpredictable load spikes when large PG owners onboard hundreds of residents simultaneously. Railway auto-scaling needs stateless .NET API pods.

RentFlowCatchMomentRailwayHorizontal

⚡

Reliability

FOUNDATIONS

System continues to work correctly even when things go wrong. Fault-tolerant through redundancy, replication, and failover. Mean Time Between Failures (MTBF) and Mean Time To Recovery (MTTR) are key metrics.

FBT APPLICATION
Zentra MUST be highly reliable — every FBT product depends on it for auth. Single Zentra failure = all products down. Railway multi-instance deployment with health checks and auto-restart.

Zentra CriticalMTBF/MTTRRedundancy

🟢

Availability

FOUNDATIONS

Percentage of time system is operational. 99.9% = 8.7 hours downtime/year. 99.99% = 52 minutes/year. 99.999% = 5 minutes/year. Availability = MTBF / (MTBF + MTTR). High availability requires eliminating single points of failure.

FBT APPLICATION
RentFlow SLA target: 99.9% (8.7hrs/yr). Zentra: 99.95%. CatchMoment GPU processing can be 99.5% (processing delays acceptable, not outages). FIROSE e-commerce: 99.9% during business hours.

SLA Targets99.9%SPOF elimination

⚖️

CAP Theorem

DISTRIBUTED THEORY

A distributed system can guarantee only 2 of: Consistency (all nodes see same data), Availability (every request gets a response), Partition Tolerance (system works despite network splits). CP systems (PostgreSQL), AP systems (Cassandra), CA (impossible in distributed systems).

FBT APPLICATION
RentFlow payment data = CP (consistency critical, can't double-charge). CatchMoment video metadata = AP (availability over perfect consistency, eventual sync is fine). Zentra tokens = CP (auth must be consistent).

RentFlow: CPCatchMoment: APZentra: CP

🌊

PACELC Theorem

EXTENDED CAP

Extends CAP: in case of Partition (P): choose Availability or Consistency. Else (E): choose Latency or Consistency. More nuanced — even without partitions, there's a latency vs consistency trade-off. DynamoDB: PA/EL. PostgreSQL: PC/EC.

FBT APPLICATION
RentFlow reservation system: PC/EC — consistency always wins. CatchMoment event uploads: PA/EL — low latency upload matters more than immediate consistency across nodes.

PA/ELPC/ECTrade-offs

🔗

Consistent Hashing

DATA DISTRIBUTION

Hash ring where nodes and keys are placed. When a node joins/leaves, only K/N keys need redistribution (K=keys, N=nodes). Virtual nodes improve load distribution. Used by Cassandra, DynamoDB, CDNs.

FBT APPLICATION
CatchMoment video upload routing — consistent hashing routes uploads to the same processing node for a given event, enabling local caching. RentFlow Redis cluster uses consistent hashing for session distribution across cache nodes.

CatchMomentRedis ClusterVirtual nodes

📊

Load Balancing

TRAFFIC DISTRIBUTION

Algorithms: Round Robin, Weighted Round Robin, Least Connections, Least Response Time, IP Hash, Resource-Based. Layer 4 (TCP) vs Layer 7 (HTTP/content-aware). Active health checks, passive monitoring.

FBT APPLICATION
Railway provides L7 load balancing for RentFlow API. Zentra needs sticky sessions for token refresh flows — use IP Hash or cookie-based affinity. CatchMoment GPU worker pool: Least Connections to avoid overloading a single Modal instance.

Railway LBL7 HTTPLeast Connections

⚡

Caching

PERFORMANCE

Cache-aside: app checks cache, loads from DB on miss. Write-through: write to cache and DB simultaneously. Write-back: write to cache, async persist. Write-around: write to DB, bypass cache. Eviction: LRU, LFU, FIFO. Cache stampede / thundering herd prevention.

FBT APPLICATION
RentFlow: Cache-aside for property listings (Redis, 5min TTL). Write-through for occupancy status (critical consistency). Zentra: Cache-aside for token validation (LRU, TTL = token expiry - 30s). CatchMoment: Cache event metadata write-through.

RedisCache-asideWrite-throughLRU

📡

Proxies

NETWORK ARCHITECTURE

Forward proxy: client-side, hides client identity. Reverse proxy: server-side, hides server pool, adds TLS, compression, caching. Open proxy: accessible by anyone. NGINX, HAProxy, Traefik as reverse proxies. Service mesh (Istio, Linkerd) for internal.

FBT APPLICATION
Railway's built-in reverse proxy handles TLS termination for all FBT services. Vyxnos Shield is FBT's custom reverse proxy / API gateway with zero-trust enforcement. YARP in .NET 8 powers internal service routing between RentFlow, Zentra, and backend services.

Vyxnos ShieldYARPRailway Proxy

🗄️

SQL vs NoSQL

DATA STORAGE

SQL: ACID, structured, joins, vertical scaling. NoSQL types: Document (MongoDB), Key-Value (Redis, DynamoDB), Column-family (Cassandra), Graph (Neo4j). Choose based on: data structure, consistency needs, query patterns, scale requirements.

FBT APPLICATION
FBT uses PostgreSQL everywhere (ACID for financials, strong consistency). Redis for caching/sessions (key-value). CatchMoment could use MongoDB for flexible video event metadata. Future: Qdrant (vector) for AI search in CatchMoment and EduConnect.

PostgreSQLRedisQdrant VectorACID

🔢

Indexes & Efficiency

DATABASE PERF

B-Tree index: balanced tree, good for range queries. Hash index: O(1) lookup, no range queries. Bitmap index: low cardinality columns. Composite indexes: multi-column. Trade-off: faster reads, slower writes, more storage. EXPLAIN ANALYZE for query planning.

FBT APPLICATION
RentFlow: Index every FK, (tenantId, status) composite indexes, GIN index for full-text search on property descriptions. Zentra: Hash index on token lookup by jti. CatchMoment: B-tree on (eventId, createdAt) for chronological video feeds.

B-TreeCompositeGINEXPLAIN

📈

Redundancy & Replication

HIGH AVAILABILITY

Active-passive: standby takes over on failure. Active-active: all nodes serve traffic. Leader-follower replication: leader handles writes, followers serve reads. Multi-leader: conflict resolution required. Synchronous vs asynchronous replication trade-offs.

FBT APPLICATION
RentFlow PostgreSQL: Leader-follower with Railway managed DB. Read replicas for property listing queries (90% reads). Zentra: Active-passive failover for identity critical path. Future: Multi-region for RentFlow as it expands beyond Chennai.

Read ReplicasLeader-FollowerActive-Passive

📋

Distributed Systems Concepts

MODULE 02 · 18 advanced patterns

DesignGurus goes deep into the internals of how distributed systems maintain consensus, detect failures, and handle the realities of networks. These are the concepts that separate senior engineers from junior ones.

📋

Data & Storage Systems

MODULE 03 · 14 storage concepts

Comprehensive coverage of data storage patterns, from partitioning and replication to search systems and event sourcing.

🔀

Data Partitioning (Sharding)

SCALING STORAGE

Horizontal: split rows across DBs by key range or hash. Vertical: split tables by column (frequently vs infrequently accessed). Directory-based: lookup table maps keys to shards. Problems: cross-shard joins, referential integrity, rebalancing hotspots.

FBT APPLICATION
RentFlow multi-tenancy = logical sharding by tenantId. Already implemented via PostgreSQL Row-Level Security. Physical sharding needed when single PG instance becomes bottleneck — use tenantId hash → DB routing layer.

tenantId shardingRLSHash partitioning

📚

Database Replication Strategies

HIGH AVAILABILITY

Synchronous: strong consistency, higher latency. Asynchronous: lower latency, possible data loss on failure. Semi-synchronous: wait for at least one replica. Statement-based vs Row-based vs Mixed replication in PostgreSQL (WAL shipping).

FBT APPLICATION
RentFlow: Railway managed PostgreSQL with async replica for reads. 90% of property listing queries go to replica. Write goes to primary. Connection string routing via .NET EF Core interceptor or PgBouncer.

PG ReplicationRead ReplicaPgBouncer

🕒

Temporal Tables & Event Sourcing

AUDIT & HISTORY

System-versioned temporal tables track full row history. Event sourcing stores state as sequence of events. Temporal queries with AS OF SYSTEM TIME. Bi-temporal: valid time + transaction time. PostgreSQL temporal table support (system-period).

FBT APPLICATION
RentFlow rent payment history = event sourcing candidate (PaymentCreated, PaymentFailed, RefundIssued). Temporal tables for property occupancy history (who lived in Room 4B, when). Zentra audit log is event sourced by design.

Event SourcingZentra AuditBi-temporal

🔍

Search Systems (Inverted Index)

SEARCH & DISCOVERY

Inverted index maps terms → document IDs. Elasticsearch/OpenSearch builds inverted indexes. BM25 ranking algorithm. Tokenization, stemming, stop words. Vector search (dense retrieval) for semantic similarity. Hybrid search: keyword + vector.

FBT APPLICATION
RentFlow property search: PostgreSQL GIN index + pg_trgm for fuzzy matching. CatchMoment video search: Qdrant vector search for "find moments like this". EduConnect: semantic course search via Qdrant. Future: hybrid search across all FBT products.

Qdrant Cloudpg_trgmVector SearchBM25

🗂️

Object Storage Architecture

BLOB / MEDIA

Flat namespace key-value for large unstructured objects. S3-compatible APIs. Presigned URLs for secure direct uploads. Multipart upload for large files (>5GB). Object lifecycle policies. S3 Intelligent-Tiering for cost optimization.

FBT APPLICATION
CatchMoment: AWS S3 Mumbai for raw video uploads (presigned URL upload). BunnyCDN as pull-through CDN over S3. Multipart upload for events with 4K video. RentFlow: S3 for document storage (lease agreements, ID proofs). FIROSE: Product images on S3 + BunnyCDN.

AWS S3 MumbaiBunnyCDNPresigned URLsMultipart

📊

Time-Series Databases

METRICS & IOT

Optimized for time-stamped sequential data. TimescaleDB (PostgreSQL extension), InfluxDB, Prometheus. Automatic time-based partitioning. Downsampling for retention. Continuous aggregates for real-time dashboards. Ideal for metrics, IoT, financial ticks.

FBT APPLICATION
RentFlow usage metrics (daily rent collection, occupancy rates over time) → TimescaleDB or ClickHouse. CatchMoment video processing metrics (queue depth, GPU utilization over time). Future: smart property IoT (electricity/water usage meters).

TimescaleDBClickHouseIoT Future

🔄

Change Data Capture (CDC)

DATA STREAMING

Capture DB changes as a stream of events. Debezium reads PostgreSQL WAL and produces Kafka events. Enables event-driven architectures without modifying application code. Use cases: search index updates, cache invalidation, analytics pipelines, audit trails.

FBT APPLICATION
RentFlow: Debezium on PostgreSQL → Kafka → ElasticSearch for property search index auto-sync. Zentra: CDC on user/role changes → invalidate downstream caches. CatchMoment: video status changes stream to React Query clients via SSE (CDC → SSE gateway).

DebeziumWAL StreamingCache Invalidation

📈

Read Models & CQRS

QUERY SEPARATION

Separate read and write models. Write model normalised for integrity. Read model denormalised for query performance. Projections rebuild read models from domain events. Eventual consistency between write and read sides. MediatR implements CQRS dispatch.

FBT APPLICATION
RentFlow already uses MediatR CQRS. Owner dashboard read model is a denormalised view of properties + rooms + occupancy + payments. Rebuild this projection from domain events rather than complex JOIN queries — massive performance win at scale.

MediatRProjectionsEventual Consistency

📋

Communication Patterns

MODULE 04 · 10 protocols & patterns

All the ways services talk to each other: REST, GraphQL, gRPC, WebSockets, SSE, message queues, and more.

Pattern	What	Projects
REST / HTTP	Stateless resource-based API, JSON payloads, HTTP verbs	All
GraphQL	Query language — client specifies exact shape needed	RentFlow Mobile
gRPC	Binary protocol, Protocol Buffers, HTTP/2, strongly typed	CatchMoment
WebSockets	Full-duplex persistent connection, low latency bidirectional	RentFlow, CatchMoment
Server-Sent Events	Server → client push, HTTP/1.1 compatible, unidirectional	CatchMoment, RentFlow
Message Queues	Async decoupled communication via broker (RabbitMQ, Kafka, SQS)	All
Event Streaming (Kafka)	Ordered, replayable, partitioned log of events	CatchMoment, Future
Webhooks	HTTP callback — server pushes to client endpoint on event	RentFlow, FIROSE
tRPC	Type-safe RPC for TypeScript — no codegen, no schema	RentFlow FE

📋

Reliability & Resilience Patterns

MODULE 05 · 12 patterns

Circuit breakers, retries, bulkheads, timeouts, idempotency, and dead letter queues — the patterns that keep systems standing.

⚡

Circuit Breaker

FAULT TOLERANCE

Three states: Closed (normal), Open (failing fast), Half-Open (testing recovery). Prevents cascade failures. Polly v8 in .NET 8 provides circuit breaker with resilience pipelines.

FBT APPLICATION
Zentra circuit breaker on Razorpay payment calls — if Razorpay is down, open circuit immediately instead of timing out 1000 concurrent resident payment requests. Polly ResiliencePipeline already in FBT standards.

Polly v8Open/Closed/Half-OpenRazorpay

🔄

Retry with Exponential Backoff + Jitter

TRANSIENT FAULTS

Retry transient failures: 1s → 2s → 4s → 8s (exponential). Add random jitter to prevent thundering herd. Limit max retries and max delay. Polly: AddRetry() with DelayBackoffType.Exponential. Never retry on 4xx (client errors).

FBT APPLICATION
CatchMoment Modal GPU calls: retry up to 3x with exponential backoff — GPU cold starts can cause transient 503s. RentFlow SendGrid email: retry 2x. Zentra: no retry on 401 (auth failure), retry on 503 (service unavailable).

PollyJitterModal GPU

🚧

Bulkhead Pattern

ISOLATION

Isolate failures by compartmentalising resources. Separate thread pools for different services — if payment service is slow, it doesn't exhaust threads for the whole API. SemaphoreSlim in .NET. Connection pool sizing per downstream service.

FBT APPLICATION
RentFlow: Separate Polly bulkheads for (1) Razorpay, (2) SendGrid, (3) Zentra auth. If SendGrid goes down, it can't starve Razorpay connection pool. CatchMoment: GPU processing bulkhead separate from metadata API bulkhead.

SemaphoreSlimThread poolsIsolation

⏱️

Timeout & Deadline

TIME BOUNDS

Never wait indefinitely. Timeouts prevent cascading hangs. CancellationToken in .NET. Deadline propagation through microservices (gRPC deadlines). Timeout should be < upstream timeout.

FBT APPLICATION
RentFlow API endpoint timeout: 30s for most operations, 5min for report generation. Database queries: 10s. Zentra token validation: 100ms (fail fast). CatchMoment S3 upload: 5min per multipart chunk.

CancellationTokenDeadline propagation

🎯

Idempotency & Deduplication

DUPLICATE HANDLING

Idempotent operations: same request multiple times = same result. Use idempotency keys (UUID) for retryable operations. Deduplication via request ID cache or database constraints.

FBT APPLICATION
RentFlow payments: Idempotency-Key header prevents double-charging if webhook retried. Zentra token refresh: single-flight mutex already implements idempotency. CatchMoment video upload: idempotency key prevents duplicate processing.

Idempotency-KeyDeduplicationSingle-flight

📬

Dead Letter Queue (DLQ)

POISON PILL

Messages that fail processing N times go to DLQ for investigation. Prevents infinite retry loops. Manual replay after fix. RabbitMQ dead-letter exchange, Kafka DLQ topic, SQS DLQ.

FBT APPLICATION
RentFlow: Failed payment webhooks → DLQ. Manual review + replay after fix. CatchMoment: Failed video processing jobs → DLQ. FIROSE: Order processing failures → DLQ for ops team to investigate.

RabbitMQ DLXManual replay

📋

Scalability Techniques

MODULE 06 · 10 strategies

CDNs, connection pooling, async processing, query optimization, stateless services, pagination, materialized views, and batch processing.

Technique	Mechanism	Priority
CDN	Serve static assets from edge nodes closest to user. Pull-through or push CDN. Cache-Control headers control edge TTL.	Critical
Connection Pooling	Reuse DB connections rather than creating per-request. PgBouncer for PostgreSQL. ADO.NET built-in pool for .NET.	Critical
Async Processing	Offload slow operations to background workers. Message queues decouple producers from consumers.	Critical
Database Query Optimization	EXPLAIN ANALYZE, N+1 elimination, index tuning, query hints, covering indexes.	High
Stateless Services	No session state on server — enables horizontal scaling. Store session in Redis or JWT claims.	Critical
Database Connection Per-Tenant Routing	Route queries to appropriate shard based on tenant. Middleware resolves tenant and selects connection string.	High
Pagination (Cursor-based)	Never return unbounded result sets. Cursor-based for consistent results with live data. Offset-based for admin panels.	Critical
Materialized Views	Pre-computed query results stored as a table. Refreshed periodically or on-demand. Avoids expensive joins at query time.	High
Batch Processing	Process records in bulk rather than one-by-one. Bulk INSERT/UPDATE. LINQ batch operations via EF Core Extensions.	High
Lazy Loading (Application Layer)	Load data only when needed. Defer expensive operations. Load plugins on demand (relates to plugin architecture).	High

📋

Security & Authentication

MODULE 07 · 8 security patterns

OAuth 2.0, OIDC, RBAC, ABAC, API keys, zero trust, secrets management, and OWASP Top 10 prevention.

🔐

OAuth 2.0 / OIDC

IDENTITY

Authorization Code + PKCE for web/mobile. Client Credentials for M2M. Implicit flow deprecated. OIDC adds identity layer (ID token) over OAuth 2.0 (access token). Refresh token rotation prevents token theft replay.

FBT APPLICATION
Zentra IS this. FBT built a complete OAuth 2.0 / OIDC provider. All FBT products (RentFlow, CatchMoment, FIROSE apps) use Zentra as their identity provider. The refresh token race condition you fixed with single-flight mutex is directly from this section.

Zentra CorePKCERefresh Rotation

🎯

RBAC & ABAC

AUTHORIZATION

RBAC: roles define permissions (Owner can read/write properties, Resident can read only). ABAC: attribute-based (owner can only see their own properties). Policy-based authorization in .NET. Claims in JWT encode roles. Claim-based access control.

FBT APPLICATION
Zentra manages roles: SuperAdmin, PGOwner, Manager, Resident. RentFlow enforces ABAC: Owners can only manage properties they own (attribute: ownerId = current user). .NET Policy: RequireClaim("rentflow:manage:property"). RemoveRoleClaimsHandler handles role changes.

Zentra RolesRentFlow ABACClaims-based

🛡️

API Key Management

M2M AUTH

API keys for machine-to-machine auth. Hash keys before storing (PBKDF2 or bcrypt). Key prefix for identification (sk_live_, pk_test_). Scoped permissions per key. Key rotation without downtime. Rate limit per key. Never store plaintext keys.

FBT APPLICATION
Zentra API Resources section manages API keys for FBT internal services. RentFlow backend calls Zentra with a service API key (not user token). CatchMoment's Modal GPU calls use Anthropic/Modal API keys managed through Zentra's secret management (not hardcoded).

Zentra API KeysPBKDF2 hashScoped perms

🔒

Zero Trust Architecture

NETWORK SECURITY

Never trust, always verify. Verify every request regardless of network origin. mTLS for service-to-service. Least privilege access. Micro-segmentation. Identity is the new perimeter. Assume breach mentality — design for compromise containment.

FBT APPLICATION
Vyxnos Shield is FBT's zero-trust API gateway project. VIRV scoring, Policy Genome, Synaptic Router are FBT's custom zero-trust components. All RentFlow internal service calls go through Zentra token verification — even internal. mTLS between CatchMoment microservices.

Vyxnos ShieldmTLSLeast privilege

🔑

Secrets Management

CREDENTIALS

Never store secrets in code or environment variables in source control. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault. Secret rotation without redeployment. Secret versioning. Injection at runtime via sidecar or SDK. Audit access to secrets.

FBT APPLICATION
RentFlow: Railway environment variables (encrypted at rest). Production: migrate to AWS Secrets Manager for rotation. Zentra manages signing keys for JWTs — rotate quarterly. CatchMoment: Modal API key, AWS S3 credentials via Railway secrets. @t3-oss/env-nextjs validates at build time.

Railway SecretsAWS SMKey Rotation

🚫

Input Validation & OWASP Top 10

APPLICATION SECURITY

OWASP Top 10: Injection, Broken Auth, XSS, IDOR, Security Misconfiguration, Vulnerable Components, etc. Parameterized queries prevent SQL injection. Server-side validation always (never trust client). CSP headers prevent XSS. CORS policy enforcement.

FBT APPLICATION
All FBT .NET APIs: FluentValidation server-side on every command handler. EF Core parameterized queries prevent SQLi. Next.js CSP headers configured in next.config.ts. Zentra: PKCE prevents auth code interception (OWASP ASVS L2). No dangerouslySetInnerHTML in React.

FluentValidationOWASPCSPPKCE

📋

Observability & Monitoring

MODULE 08 · 7 pillars

Structured logging, distributed tracing, metrics (RED/USE), alerting, SLO/SLI/SLA definitions.

📝

Structured Logging

PILLAR 1

JSON-formatted logs with consistent fields. Correlation ID threads through all services for request tracing. Log levels: Trace → Debug → Info → Warn → Error → Fatal. Log sampling at high volume. Centralized aggregation (Seq, Loki, CloudWatch).

FBT APPLICATION
Serilog + Seq for all .NET 8 services. Every log includes: tenantId, userId, correlationId, requestId. structlog for any Python services (CatchMoment AI). tracing crate in Rust (Vyxnos Shield). OpenTelemetry log bridge for unified collection.

SerilogSeqCorrelation IDJSON logs

📊

Distributed Tracing

PILLAR 2

Track a single request across multiple services. TraceId + SpanId + ParentSpanId. W3C Trace Context standard. Jaeger, Zipkin, Honeycomb, Tempo as backends. OpenTelemetry SDK for instrumentation. Sampling: head-based vs tail-based.

FBT APPLICATION
OpenTelemetry SDK in all .NET 8 services. Trace: RentFlow API → Zentra Auth → Payment → DB. See exact span where latency occurs. CatchMoment: Trace video upload → S3 → Temporal → Modal GPU → highlight generation. Grafana Tempo as backend.

OpenTelemetryGrafana TempoTraceId propagation

📈

Metrics (RED + USE)

PILLAR 3

RED: Rate, Errors, Duration (for services). USE: Utilization, Saturation, Errors (for resources). Prometheus for collection. Grafana for dashboards. Counters, Gauges, Histograms, Summaries. SLI/SLO/SLA definitions. Alert on SLO breach, not individual errors.

FBT APPLICATION
System.Diagnostics.Metrics (.NET 8) + OpenTelemetry Metrics → Prometheus → Grafana. Key FBT metrics: RentFlow booking conversion rate, Zentra token issuance rate, CatchMoment video processing P95 latency, GPU utilization on Modal.

PrometheusGrafanaRED/USESLO alerts

🚨

Alerting & SLO/SLI/SLA

RELIABILITY

SLI: actual measurement (P99 latency = 180ms). SLO: target (P99 latency ≤ 200ms). SLA: contract with consequences. Error budget: how much SLO slack before burning budget. Alert on symptom (user-facing degradation), not cause (CPU spike).

FBT APPLICATION
RentFlow: SLO — 99.9% availability, P99 API latency ≤500ms, booking success rate ≥99.5%. Zentra: SLO — token issuance P99 ≤100ms, 99.95% availability. CatchMoment: SLO — video ready within 2min of upload P95. Alert via PagerDuty or Slack.

Error BudgetPagerDutyZentra SLO

📋

Classic System Designs → FBT Analogs

MODULE 09 · 18 design problems mapped

DesignGurus walks through 18 classic system design interview problems. Each is directly analogous to something FBT is building or will build. Learn the pattern, apply to FBT.

🔗

URL Shortener

HASH + REDIRECT

Base62 encoding, hash collision handling, redirect at CDN edge, analytics tracking

FBT APPLICATION
RentFlow QR codes for property self-check-in + referral links

📄

Pastebin

CONTENT STORE

Content-addressed storage, expiry, read-heavy caching, shareable links

FBT APPLICATION
RentFlow notice board, CatchMoment event brief sharing

📸

Instagram

MEDIA + SOCIAL

Photo CDN, news feed ranking, push vs pull, follow graph, image resizing

FBT APPLICATION
CatchMoment event gallery, FIROSE product catalog

📁

Dropbox

FILE SYNC

Chunked upload, content dedup, sync engine, conflict resolution, offline support

FBT APPLICATION
RentFlow document management (leases, IDs, receipts)

💬

Facebook Messenger

REAL-TIME MESSAGING

WebSocket, message ordering, delivery receipts, offline queue, push notifications

FBT APPLICATION
RentFlow resident ↔ manager communication

🐦

Twitter

SOCIAL GRAPH + FEED

Fan-out on write, Redis sorted sets for timeline, trending, search indexing

FBT APPLICATION
EduConnect student activity feed, FIROSE brand updates

▶️

YouTube / Netflix

VIDEO STREAMING

HLS/DASH, transcoding pipeline, CDN multi-tier, adaptive bitrate, recommendation

FBT APPLICATION
CatchMoment — core architecture mirror

🔤

Typeahead

SEARCH UX

Trie or Elasticsearch prefix, popularity ranking, debounce, cache suggestions

FBT APPLICATION
RentFlow property search, EduConnect course search

🚦

Rate Limiter

PROTECTION

Token Bucket, Sliding Window, Redis atomic ops, distributed coordination

FBT APPLICATION
Zentra auth endpoints, all FBT public APIs

🗺️

Yelp / Proximity

GEO SEARCH

GeoHash, QuadTree, PostGIS, radius search, map tile caching

FBT APPLICATION
RentFlow "PGs near me", maintenance dispatch routing

🚕

Uber / Lyft

DISPATCH SYSTEM

Location streaming, nearest-N, matching, surge pricing, ETA

FBT APPLICATION
RentFlow maintenance crew dispatch to PGs

🎟️

Ticketmaster

CONCURRENT BOOKING

Pessimistic locking, reservation expiry, atomic saga, overbooking prevention

FBT APPLICATION
RentFlow bed booking concurrency — identical problem

📋

FBT Project System Design Map

MODULE 10 · complete architecture blueprint

Treating every DesignGurus lesson as a direct specification for FBT's architecture. RentFlow = Ticketmaster + Uber + Messenger. CatchMoment = YouTube + Dropbox. Zentra = Auth0 architecture.

RentFlow — Complete System Architecture

Zentra — Identity Platform Architecture

CatchMoment — AI Video Platform Architecture

📋

FBT Implementation Roadmap

MODULE 11 · apply now · phased plan

Apply these DesignGurus lessons immediately. Phased plan across Q1-Q4 for all FBT products.

Q1Foundation HardeningImmediate · All Projects

Bloom filter (Zentra), bulkheads (RentFlow), cursor pagination (all APIs), composite indexes (RentFlow DB), SLO definitions (all products), CSP headers (all frontends). These are small changes with massive reliability impact.

01Add Bloom filter to Zentra token revocation fast-path — 99% of valid tokens skip Redis lookupDay 1

02Implement Redis read replica for RentFlow property listing queries (huge read volume)Week 1

03Add Polly bulkheads for each external service (Razorpay, SendGrid, Zentra) in RentFlowWeek 1

04Define SLOs for all FBT services (RentFlow 99.9%, Zentra 99.95%, CatchMoment 99.5%)Week 1

05Implement cursor-based pagination for all RentFlow list endpoints (replace offset pagination)Week 2

06Add composite indexes (tenantId, status, createdAt) to all RentFlow high-traffic tablesWeek 2

ZentraRentFlowLow riskHigh impact

Q2Scalability & ObservabilityMonth 1–2 · RentFlow Priority

OpenTelemetry distributed tracing, PostgreSQL read replica routing, materialized views for dashboards, booking saga with Temporal/MassTransit, rate limiting on Zentra. Start measuring before optimising.

07Set up OpenTelemetry distributed tracing across RentFlow → Zentra → DB for latency debuggingMonth 1

08Implement booking saga in RentFlow: ReserveBed → ProcessPayment → Confirm with Temporal or MassTransit SMMonth 1

09Add Sliding Window rate limiting to Zentra auth endpoints via ASP.NET Core Rate Limiting middlewareMonth 1

10PostgreSQL materialized views for RentFlow owner dashboard stats (refresh every 5min via pg_cron)Month 2

11CatchMoment: HLS transcoding pipeline via FFmpeg on Modal — adaptive bitrate (360p/720p/1080p)Month 2

12Add Leader Election to RentFlow background job workers to prevent duplicate Hangfire job executionMonth 2

SagaTracingRead replicasRate limiting

Q3CatchMoment Video PipelineMonth 3–4 · CatchMoment Priority

Full HLS transcoding via Modal, Qdrant vector search for semantic video search, Temporal multi-stage saga for processing, SSE progress streaming, BunnyCDN HLS delivery optimisation, DLQ for failed jobs.

13Complete Qdrant vector search integration for semantic video moment findingMonth 3

14Implement Server-Sent Events (SSE) for real-time video processing progress to frontendMonth 3

15Set up DLQ handling for failed video processing jobs with automated alertingMonth 3

HLSQdrantTemporalSSE

Q4FBT Platform Event Bus & Future ProductsMonth 5–6 · Platform

Kafka event bus bridging RentFlow, Zentra, CatchMoment. Schema registry for event contracts. CDC from RentFlow PostgreSQL. Begin EduConnect system design. Vyxnos Shield zero-trust gateway hardening.

16Kafka event bus setup and cross-product event contract schema registryMonth 5

17Enable CDC on RentFlow PostgreSQL for event streaming via DebeziumMonth 5

18EduConnect system design review against DesignGurus patterns (Typeahead + Twitter/Feed)Month 6

KafkaCDCVyxnosEduConnect