← Back to Topics

Topic 5: Databases in Software Architecture & Design

Microservices Patterns, Distributed Transactions, Event-Driven Architectures, CAP Theorem

Topic Overview

Database design decisions fundamentally constrain system architecture, particularly in distributed systems where the CAP theorem forces trade-offs between consistency, availability, and partition tolerance. Microservices architectures require each service to own its database, eliminating shared databases that create tight coupling. This independence prevents distributed ACID transactions, necessitating patterns like Sagas that use compensating transactions for eventual consistency. Event-driven architectures with event sourcing store append-only event logs rather than current state, enabling temporal queries and audit trails at the cost of increased complexity. CQRS separates read and write models, optimizing each for different access patterns. Students must evaluate when these patterns provide architectural benefits versus when they introduce unnecessary complexity, and understand how database choices determine system scalability and consistency guarantees.

Student Presentation Assignments

Student 1:Database Design in Microservices

Required Coverage:

  • Must compare monolith vs microservices database implications, analyzing how data access patterns change and why
  • Must explain database-per-service pattern, specifying benefits (independence, scalability) and challenges (data consistency, transactions)
  • Must analyze shared database anti-pattern, explaining why it breaks microservices principles with concrete examples (e.g., cross-service joins, schema coupling), focusing on database design implications, not generic microservices theory
  • Must explain data ownership and boundaries, specifying how to define service responsibilities and identify boundary violations with concrete database design examples (e.g., foreign key constraints across services), not merely conceptual service boundaries
  • Must evaluate schema duplication trade-offs, analyzing consistency vs independence and when duplication is acceptable
  • Must compare data synchronization strategies (events, APIs, shared caches), evaluating database design trade-offs and specifying when services need shared data, not just listing synchronization mechanisms

Student 2:Distributed Transactions & Saga Pattern

Required Coverage:

  • Must analyze why ACID doesn't scale in microservices, quantifying coordination overhead and latency implications
  • Must explain two-phase commit problems, specifying blocking behavior, failure modes, and scalability limitations
  • Must compare Saga pattern approaches (orchestration vs choreography), analyzing trade-offs in complexity, coupling, and observability
  • Must explain compensating transactions, specifying rollback strategies and identifying scenarios where compensation fails (including business-level failures), analyzing database state consistency implications
  • Must analyze failure scenarios, explaining how to handle partial failures and recovery mechanisms
  • Must evaluate when to use sagas vs alternatives (eventual consistency, idempotency), justifying design decisions

Student 3:Event-Driven Architectures & Databases

Required Coverage:

  • Must explain event sourcing fundamentals, comparing storing events vs state and analyzing when each is appropriate
  • Must explain CQRS pattern, specifying how read and write models differ and why separation improves performance
  • Must analyze append-only logs as a database storage pattern, explaining implementation approaches and storage considerations (compression, retention), focusing on database design implications, not message broker tutorials
  • Must explain materialized views, specifying how read models are built from events and trade-offs in freshness vs performance
  • Must evaluate persistence implications, quantifying storage requirements and explaining replay capabilities and limitations
  • Must analyze trade-offs: complexity (eventual consistency, replay), consistency guarantees, and performance characteristics

Student 4:CAP Theorem & Schema Evolution

Required Coverage:

  • Must explain CAP theorem practically, specifying how systems choose between consistency and availability during partitions
  • Must analyze real-world interpretations, evaluating how actual systems (e.g., DynamoDB, Cassandra) make CAP choices
  • Must compare schema evolution strategies (backward compatibility, versioning, breaking changes), analyzing trade-offs
  • Must explain backward compatibility techniques (additive changes, default values), specifying trade-offs in schema flexibility
  • Must explain versioned APIs and migrations, specifying how database schema changes affect API design and how to manage changes without breaking clients, tying database evolution to system architecture
  • Must evaluate at least one practical example, analyzing how a real system handles CAP trade-offs and schema evolution

Presentation Requirements

All presentations must be 17–20 minutes in duration and include the following components:

Note: Presentations that only summarize definitions, list features, or copy diagrams without interpretation will receive low marks. Each presentation must demonstrate analytical reasoning through comparisons, trade-off analysis, and justification of design decisions. Reading slides verbatim or presenting material that could be satisfied by reading documentation will be penalized.

Report Requirement: In addition to the presentation, each student must submit an individual PDF report. See Seminar Report Requirements for format, content, and submission details.

Evaluation Criteria

Criterion Weight Description
Technical Correctness 30% Accuracy of technical content, correct use of terminology, absence of errors
Depth of Understanding 25% Goes beyond surface-level definitions, demonstrates system-level comprehension
Clarity and Structure 20% Logical flow, clear explanations, appropriate use of examples and visuals
Use of Examples and Trade-offs 15% Concrete examples, discussion of limitations, comparison with alternatives
Slide Quality and Time Management 10% Professional formatting, appropriate pacing, stays within time limit

Recommended References

Books:

Documentation:

Academic / Technical: