Chapter 35: Key Takeaways

1. Modern Applications Need Multiple Access Patterns

No single data access pattern serves all needs. Mobile apps require REST APIs with low latency. Analytical dashboards benefit from GraphQL's flexible querying. Real-time systems need event streams. Batch programs still use JDBC directly. A well-designed architecture provides the right access pattern for each consumer.

2. z/OS Connect EE Is the Fastest Path to Mainframe APIs

For organizations running DB2 on z/OS, z/OS Connect EE exposes stored procedures as REST APIs without custom application code. It runs on the same LPAR as DB2 (eliminating network latency), integrates natively with RACF security, generates OpenAPI documentation automatically, and qualifies for zIIP offload to reduce costs.

3. Db2 REST Services Are Useful for Prototyping

Db2 LUW's built-in REST services quickly expose SQL statements and stored procedures as HTTP endpoints. They are excellent for internal tools and rapid prototyping but lack the authentication, rate limiting, and response transformation needed for production external APIs.

4. Application-Layer APIs Provide Maximum Control

Spring Boot, Node.js, and Python Flask give full control over API design, error handling, security, and JSON formatting. Use them when you need custom response shapes, complex validation, or integration with external services. The stored procedures from Chapter 34 remain the backend — the API layer adds the HTTP interface.

5. GraphQL Solves Over-Fetching and Under-Fetching

For complex data models where different clients need different data shapes, GraphQL allows clients to request exactly the fields they need in a single request. The N+1 query problem is the primary performance concern — solve it with DataLoader batching or SQL query lookahead that generates a single optimized DB2 query.

6. Kafka CDC Transforms DB2 Into an Event Source

Debezium and IBM InfoSphere Data Replication capture DB2 changes from the transaction log and publish them as Kafka events. This enables real-time fraud detection, notifications, analytics pipelines, and CQRS architectures — all without modifying the DB2 application layer.

7. Exactly-Once Semantics Require End-to-End Design

In financial systems, duplicate events cause real harm. Achieve exactly-once processing through idempotent Kafka producers, transactional consumers, and database-level deduplication tables. Design every consumer to be idempotent from the start.

8. Avoid Microservices Data Access Anti-Patterns

Never let multiple services share DB2 tables directly (creates coupling). Never let frontends access DB2 directly (creates security risks). Never design chatty APIs that require many round-trips (creates latency). Design APIs around business use cases, not database tables.

9. API Security Is Defense in Depth

Protect DB2-backed APIs with multiple layers: TLS for transport encryption, OAuth2/JWT for authentication, role-based authorization in the API layer, DB2 EXECUTE privileges for procedure-level access control, input validation against SQL injection, and rate limiting to prevent abuse.

10. Connection Pooling and Caching Are Non-Negotiable

Every API request needs a DB2 connection. HikariCP (Java), ibm_db Pool (Node.js), or SQLAlchemy QueuePool (Python) maintain ready connections. Size the pool based on concurrent request volume and average query time. Cache immutable or slowly-changing data (interest rates, branch info, fee schedules) to reduce DB2 load. Use keyset pagination instead of offset pagination for deep result sets.