Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
60 results for “Continuous Integration Discipline”
Integration Frequency
How often each engineer merges to the mainline — the measurement that distinguishes continuous integration from having a CI server.
Branch Lifetime
How long a branch lives before being merged, which determines integration pain and is the practical measure of whether integration is continuous.
CI/CD
Merging work continuously into a shared trunk with automated verification, and keeping every commit in a state that could be released.
Abstraction Level Discipline
Keeping each diagram to a single level of zoom, and providing separate diagrams for each level rather than one diagram attempting all of them.
Continuous Compliance
Producing compliance evidence automatically and continuously from the systems themselves, rather than reconstructing it before an audit.
Continuous Profiling
Sampling CPU, memory and lock profiles from production continuously at low overhead, so resource usage can be attributed to specific code paths.
Decommissioning Discipline
The work of actually switching a legacy system off, which is where migration savings are realised and which is routinely left undone.
Enterprise Integration Patterns
A catalogue of named, composable messaging patterns — router, translator, aggregator, splitter, filter, dead letter channel — that gives integration work a shared vocabulary.
Etsy's Continuous Deployment
Etsy moved from infrequent, risky releases to dozens of deploys a day, demonstrating that deployment frequency and stability improve together rather than trading off.
Event-Driven Integration
Systems integrating by publishing and consuming events rather than by calling each other's APIs.
Executive Summary Discipline
Leading with the recommendation and its business consequence, compressed to what an executive audience can act on in a few minutes.
File-Based Integration
Exchanging data as files on a schedule via SFTP or shared storage — dated, still ubiquitous, and workable when its failure modes are handled explicitly.
Integration Landscape
The inventory of connections between systems, which is usually larger, less documented and more expensive than the application inventory itself.
Log Level Discipline
Consistent semantics for log severity so that levels can be used for routing, alerting and cost control.
Review Scope Discipline
Stating what an architecture board does not review, which is what determines whether it stays useful or becomes a queue.
Shared Database Integration
Two or more applications reading and writing the same database directly — the most damaging integration pattern and the hardest to unwind.
ADR Lifecycle
The states an architecture decision record moves through — proposed, accepted, superseded, deprecated — and the discipline that keeps the set trustworthy.
API Gateway
A single entry point in front of a set of services that handles authentication, rate limiting, routing and protocol translation.
Anti-Corruption Layer
A translation layer that converts a legacy or external system's model into your own, so its concepts do not leak into your domain.
Backward Compatibility
The property that a new version of a producer continues to work with clients written against the old version.
Change Data Capture
Publishing a stream of a database's row-level changes by reading its replication log, without modifying the application that owns it.
Consumer-Driven Contract
A contract derived from what consumers actually use, published to the provider, and verified in the provider's own build.
Context Map
A diagram of the bounded contexts in a system and the relationship type between each pair, making integration expectations and power dynamics explicit.
Contract Testing
Verifying that a provider satisfies the expectations each of its consumers actually relies on, without running all the services together.
Control Test Automation
Executing a control's test continuously against the whole population rather than sampling it annually, which changes both the detection latency and the strength of the evidence.
Dead Letter Queue
A separate queue that receives messages which could not be processed after a set number of attempts, so they neither block the consumer nor disappear.
Event Notification vs Event-Carried State
Whether an event carries only the fact that something happened, or also the data a consumer needs to act on it.
Event Versioning
Evolving event schemas without breaking consumers that may read messages written months earlier.
A core mainframe system with no API supports nightly batch file exchange only. The business needs near-real-time order status. Design the integration.
Establish the real constraint "No API" usually means no API the mainframe team will build on your timeline . Find out what exists: message queue interfaces, dat
Integration failures between 30 services are found in a shared staging environment, days after merge. Propose a change.
Why the current model fails A shared staging environment is a serialised, high latency feedback channel . Failures are found late, attribution is ambiguous (who
Run a threat model on a new payment integration: our service calls a third-party payment provider and receives webhooks. Where are the interesting threats?
Draw the boundaries first Three trust boundaries, and nearly every interesting threat lives on one of them: 1. User → our service (untrusted input, authenticate
Six teams share one integration test environment. Bookings are made a week ahead and releases slip when someone overruns. How do you fix it?
Name the cost first The queue is not an inconvenience; it is lead time. Measure it: for the last twenty changes, how many days elapsed between "ready to test" a
The business has selected a SaaS product. You are asked to review the integration architecture after the contract is signed. What do you do?
Accept the position and be useful within it The selection cannot be reopened, and arguing about the process will spend credibility for nothing. What can still c
A downstream team needs to react to order changes. The order service can publish events, or they can consume CDC from its database. Which, and why?
The recommendation: published events, with CDC as the mechanism if needed The distinction that matters is what the consumer becomes coupled to . CDC consumed di
A release must rename a heavily used database column and ships tonight. The team proposes doing the rename in the deployment. What is wrong, and what do you propose?
What is wrong A rename is not additive. During a rolling deployment both versions of the application run simultaneously: one expects the old name, one the new.
A service writes to its database and then publishes an event to Kafka. Sometimes consumers see an event for a record that does not exist, and sometimes a record exists with no event. Why, and how do you fix it?
What the interviewer is testing Recognition of the dual write problem — one of the most common defects in event driven systems and one that testing rarely catch
A team proposes exposing their service's database change stream via CDC so other teams can consume it, avoiding the work of building an event API. What is your assessment?
Name what is actually being proposed The proposal is to publish the service's internal schema as its integration contract. CDC does not emit domain events; it e
An order service must notify inventory, billing, shipping and analytics when an order is placed. Synchronous calls or events? Justify your choice per consumer.
What the interviewer is testing Whether you apply the decision per interaction rather than adopting one style globally. The framing that matters Synchronous cal
An order service publishes events consumed by six teams. Every consumer immediately calls back for order details. What is wrong and what do you change?
The failure Thin notification events ("order 123 changed") produce a callback stampede : every event triggers six synchronous calls back to the producer, and th
Continuous Integration Discipline
Integrating to the mainline daily, and the test speed and review culture that requires.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
API & Integration
General material on integrating systems through contracts.
Continuous Controls Monitoring
Testing controls continuously instead of sampling them once a year.
Continuous Learning
Staying current without chasing every new thing.
Enterprise Integration
Estate-wide integration strategy, standards and shared infrastructure.
Event-Driven Integration
Publishing facts rather than commands, and versioning event schemas.
Integration Patterns
Routers, translators, splitters, aggregators and dead letter channels.
Integration Test Boundaries
What sits inside a test's boundary, what is faked, and the confidence that follows.
Legacy Integration
Reaching systems that cannot change, without importing their model.
Legacy Integration Patterns
Anti-corruption layers, adapters and CDC against systems that cannot change.
Partner & B2B Integration
External contracts, onboarding, sandboxes and long deprecation windows.
API Documentation
OpenAPI as a machine-checked contract rather than as prose.
API Error Handling
Error shapes, retryability signals and machine-readable causes.
API Versioning
URL, header and account-pinned versioning, and who carries the burden.
APIs as Products
Ownership, lifecycle, deprecation policy and developer experience.
Backward Compatibility
Which changes are safe, and how to make breakage a build failure.
Change Management vs CD
Reconciling CAB-era controls with continuous delivery without pretending either away.
Contract Testing
Verifying what consumers actually rely on, without a shared environment.