A 13-section interactive reference guide covering the core software engineering topics every developer and architect uses across the full product lifecycle. Includes Big O complexity tables, system design patterns (CAP theorem, SOLID), database selection guides, REST/GraphQL comparison, CI/CD pipeline strategies, AWS core services, OWASP Top 10, testing pyramid, and observability pillars.
Each section targets a core discipline: SDLC and Agile/Scrum methodologies (Section 1), data structures and algorithm complexity with Big O reference table (Section 2), system design principles including CAP theorem and SOLID (Section 3), SQL/NoSQL database selection and normalization (Section 4), REST and GraphQL API design with full HTTP status code reference (Section 5), microservices vs monolith tradeoffs and circuit breaker/saga patterns (Section 6), DevOps CI/CD pipelines and deployment strategies (Section 7), cloud architecture on AWS/Azure/GCP with the Well-Architected Framework (Section 8), security covering OWASP Top 10 and authentication flows (Section 9), testing pyramid and TDD practices (Section 10), performance engineering with SLI/SLO/SLA and caching strategies (Section 11), observability with metrics/logs/traces (Section 12), and a complete quick reference for the most commonly looked-up facts (Section 13).
Use the Prev / Next buttons at the bottom, or press the arrow keys on your keyboard. Click the ☰ menu button in the top-right to open the table of contents and jump to any section. The gold progress bar at the top tracks your position through all 13 sections.
This reference is designed for software engineers preparing for system design interviews, technical leads making architecture decisions, full-stack developers expanding their knowledge of the wider engineering landscape, and anyone who needs a fast, structured reference without wading through a textbook. Each section is distilled to the facts and formulas that come up repeatedly in real engineering work.
The Big O table (Section 2) is the single most frequently consulted reference in algorithm interviews and code reviews. The CAP theorem and SOLID sections (Section 3) form the foundation of every system design discussion. The HTTP status codes table (Section 5) and DORA metrics (Section 7 and 13) are reference-grade material for day-to-day API development and DevOps practice. The OWASP Top 10 (Section 9) should inform every code review checklist.
The CAP theorem states that a distributed system can only guarantee two of three properties simultaneously: Consistency (all nodes return the same, most recent data), Availability (every request gets a response, though it may not be the most recent), and Partition tolerance (the system continues operating even if network messages are dropped between nodes). In practice, network partitions do happen, so the real choice is between CP (consistent but may become unavailable during a partition — HBase, ZooKeeper, etcd) and AP (always available but may return stale data during a partition — Cassandra, DynamoDB, CouchDB). Relational databases on a single node have no partition tolerance to sacrifice and can guarantee CA.
REST uses multiple endpoints (one per resource) with fixed response shapes — GET /users/123 always returns the full user object. This leads to over-fetching (getting data you don't need) or under-fetching (needing multiple requests to compose a view). GraphQL uses a single endpoint where the client specifies exactly what fields it needs in each query, eliminating both problems. REST is simpler, better-understood, easier to cache (HTTP caching works natively), and preferred for public APIs and simple use cases. GraphQL excels for complex client needs (mobile apps needing efficient data fetching), multiple client types needing different data shapes, and rapid product iteration where API shapes change frequently.
DORA (DevOps Research and Assessment) identified four metrics that predict software delivery performance: (1) Deployment Frequency — elite performers deploy multiple times per day; (2) Lead Time for Changes — elite performers take less than one hour from commit to production; (3) Change Failure Rate — elite performers have less than 5% of deployments causing incidents; (4) Mean Time to Recover (MTTR) — elite performers restore service in less than one hour. These metrics correlate with organizational performance (revenue, market share, profitability). Improving CI/CD pipelines, testing automation, feature flags, and observability are the primary levers.
Authentication answers "who are you?" (identity verification) — use established protocols: JWT with RS256 signing for stateless APIs, OAuth 2.0 + OIDC for third-party login (Google, GitHub), or session cookies for traditional web apps. Never roll your own crypto. Authorization answers "what can you do?" (permissions) — implement Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) at the server side. Always validate authorization server-side; client-side permission checks are UX only. Use the principle of least privilege: users should only have access to exactly what they need for their role, and that access should be audited.