Lesson 1

Module 8 established the first two categories of web development software — languages and applications — and examined how modern front-end frameworks, back-end runtimes, and middleware connect those layers into functioning web systems. Module 9 completes the picture by examining the remaining two categories: databases and bundled software solutions.
These two categories represent the decisions with the longest operational consequences in any web project. A poorly chosen database schema is difficult and expensive to migrate once production data accumulates. A bundled platform that cannot integrate with existing systems creates integration debt that compounds over years. Understanding how to evaluate databases and bundled solutions — not just what they are, but how to select them against specific project requirements — is the practical outcome this module is designed to deliver. The module also introduces the discipline of software requirements planning as the prerequisite step that makes database and bundled solution selection rational rather than arbitrary. Before a team can evaluate whether PostgreSQL or MongoDB is the right fit, or whether Shopify or a custom headless commerce stack serves the business better, they need a clear articulation of what the system must do, how it must perform, and what constraints it must satisfy.

Software requirements planning is the process of translating business objectives into specific, testable criteria that a technical system must satisfy. It precedes all technology selection decisions — database choice, platform selection, and architecture design, because those decisions cannot be made rationally without knowing what the system is required to do.

• Requirements divide into two categories that operate at different layers of the system. Functional requirements define what the system does: a product catalog must support faceted filtering by category, price range, and availability; a user account system must support OAuth 2.0 login via Google and Apple; an order management system must send fulfillment notifications via webhook to a third-party logistics provider. Functional requirements are expressed as specific, verifiable behaviors.
• Non-functional requirements define how well the system performs those behaviors under real-world conditions: the product catalog must return filtered results within 200 milliseconds at 10,000 concurrent users; the checkout flow must achieve a Lighthouse performance score above 90 on mobile; the system must maintain 99.9% uptime measured monthly. Non-functional requirements constrain the architecture — a 200ms response time requirement at scale rules out certain database designs and mandates caching strategies regardless of which platform is chosen.
• The practical requirements planning process for a web project involves five steps. First, stakeholder identification: the people whose needs the system must serve include end users, internal operators, third-party integrators, and compliance auditors — each with distinct requirements that may conflict. Second, requirements elicitation: structured interviews, user story workshops, and review of existing system documentation surface requirements that stakeholders may not articulate spontaneously. Third, requirements documentation: a Software Requirements Specification (SRS) following IEEE structure creates a baseline that controls scope and provides the criteria against which the delivered system is measured. Fourth, prioritization: the MoSCoW method (Must-have, Should-have, Could-have, Won't-have) separates launch-blocking requirements from post-launch enhancements. Fifth, change management: requirements evolve during development, and a formal change control process using tools like Jira or Linear tracks those changes against their impact on scope, timeline, and cost.

The most expensive mistake in web development is selecting a platform or database before requirements are defined. A team that chooses Shopify before establishing that the business requires custom subscription billing logic will discover that Shopify's native subscription support does not meet their requirements after significant configuration work has been completed. Requirements planning prevents that category of error.

Database selection is one of the most consequential technical decisions in a web project because migrating production data between database systems is costly, risky, and time-consuming. The decision must be driven by the data requirements established in the requirements planning phase, not by team familiarity or platform defaults.
The contemporary database landscape divides into three categories. Relational databases — PostgreSQL, MySQL, SQL Server — store structured data in normalized tables with enforced relationships and ACID transaction guarantees. They are appropriate when data integrity is paramount: financial records, order histories, user account data. PostgreSQL in particular has become the default choice for new web applications due to its JSON support, full-text search capabilities, and robust extension ecosystem. Managed cloud services — AWS RDS, Google Cloud SQL, Supabase — eliminate the operational burden of self-hosting while preserving full PostgreSQL compatibility.
Document databases — MongoDB, Firestore — store data as flexible JSON documents without enforced schema. They are appropriate when data structures vary significantly across records or evolve rapidly during development: content management, user-generated content, product catalogs with heterogeneous attribute sets. MongoDB Atlas provides a fully managed cloud hosting option with global distribution and built-in search.

NewSQL and serverless databases represent a third category that has emerged to address the limitations of both. PlanetScale (built on Vitess, the MySQL scaling technology that powers YouTube) provides horizontal scaling with schema change workflows that eliminate the downtime associated with traditional database migrations. Supabase combines PostgreSQL with a real-time API layer, authentication, and storage in a single managed platform — effectively a Firebase alternative built on open standards.
Database schema design follows from data requirements. Entity-Relationship (ER) diagrams model the entities the system must track and the relationships between them before any SQL is written. Normalization to third normal form (3NF) eliminates data redundancy in relational schemas. Indexes on frequently queried columns, caching layers (Redis for session data and computed results, Memcached for simpler key-value caching), and read replicas for high-traffic read operations complete the performance architecture.
Security and compliance requirements constrain database design in ways that cannot be retrofitted easily. GDPR mandates the ability to delete all data associated with a specific user — a requirement that affects schema design if user identifiers are embedded in audit logs or denormalized into multiple tables. HIPAA requires encryption at rest and in transit, role-based access controls, and audit logging of all data access. These requirements must be established before schema design begins, not after.

The legacy approach to database integration — ADO (ActiveX Data Objects), Microsoft's data access technology for connecting ASP applications to databases — was tightly coupled to the Windows/IIS/COM ecosystem and has no role in modern web development. Contemporary applications use ORMs (Prisma for TypeScript/Node.js, SQLAlchemy for Python, Hibernate for Java) that generate type-safe database queries from application-layer code, enforce schema through migration files, and work across database providers without vendor lock-in.

Bundled software solutions combine languages, applications, databases, and supporting infrastructure into pre-integrated packages that reduce the time from decision to deployment. The trade-off is explicit: bundled solutions optimize for speed and operational simplicity at the cost of flexibility and customization depth.

• The legacy framing of bundled solutions centered on server stacks: LAMP (Linux, Apache, MySQL, PHP) and MEAN (MongoDB, Express.js, AngularJS, Node.js) were the dominant configurations of the 2000s and early 2010s. These stacks required self-hosting on dedicated servers or virtual machines, manual configuration of each component, and ongoing server administration. They were monolithic in the sense that all components ran on the same server and could not be independently scaled — a traffic spike affecting the database affected the application server simultaneously.
• Modern bundled solutions have shifted toward managed platforms and composable architectures. A small business e-commerce operation can deploy a complete online store using Shopify — which bundles hosting, database, payment processing, CDN, and SSL, without managing any infrastructure. The same Shopify instance can be extended through the Shopify Storefront API to build a custom front end in Next.js while retaining Shopify's commerce engine for catalog, inventory, and order management. This composable approach — using the bundled solution for what it does well while replacing specific components through APIs — reflects the architectural shift from monolithic bundled stacks to headless and composable commerce.
• Enterprise bundled solutions — ERP systems (SAP, Oracle NetSuite), CRM platforms (Salesforce), and marketing automation suites (HubSpot) — integrate multiple business functions into a single managed platform. These systems expose APIs that allow custom web applications to read and write data, triggering the middleware integration patterns covered in Module 8. Planning for enterprise bundled solution integration requires establishing API capability requirements early: which data must flow in which direction, at what frequency, and with what latency tolerance.
• Infrastructure-as-Code tools — Terraform and Pulumi — have emerged as the standard approach for defining and provisioning cloud infrastructure for custom bundled solutions. Rather than manually configuring cloud resources through a web console, infrastructure is defined in version-controlled configuration files that can be reviewed, tested, and applied consistently across development, staging, and production environments. Docker containerization packages application code and its dependencies into portable images; Kubernetes orchestrates those containers across server clusters, handling scaling, health monitoring, and rolling deployments without downtime.

The selection criteria for bundled solutions follow directly from the software requirements established earlier. A project with rapid deployment as a primary requirement and limited customization needs points toward managed SaaS platforms. A project with complex integration requirements, strict data residency constraints, or differentiated user experience requirements points toward custom stacks built on open-source components and deployed through container orchestration. Neither choice is inherently superior — the requirements determine the appropriate position on the trade-off spectrum.

You learned about languages and applications in Module 8. This module examines the remaining two software categories. When you have completed this module, you will be able to:

1. List the functions of databases
2. Describe the four basic database models
3. Explain the characteristics and protocols of back-end web databases
4. Explain the importance of data modeling techniques
5. Describe the functions of security software
6. Explain the types and benefits of bundled solutions, giving common examples

In the next lesson, you will learn about the standard functions of databases — what a database does for a web application, how data is stored and retrieved, and how the database layer connects to the server-side application through ORMs and query builders.