Search the practice set
126 questions, 454 terms and 400 topics in 20 areas.
60 results for “Event-Driven Integration”
Event-Driven Integration
Systems integrating by publishing and consuming events rather than by calling each other's APIs.
Event-Driven Architecture
A style in which components communicate by emitting and reacting to facts about what happened, rather than by calling each other.
Event Sourcing
Storing the full sequence of state-changing events as the system of record, and deriving current state by replaying them.
LinkedIn and the Origin of Kafka
Kafka was built to replace point-to-point data integration between many systems with a single durable log that any system could publish to and any number could read.
Webhook
An HTTP callback from a provider to a consumer-supplied URL when an event occurs, replacing polling with push.
Domain-Driven Design
Modelling software around the business domain, with boundaries drawn where the language of the business changes.
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.
Event Store
An append-only store of domain events organised into per-entity streams, serving as the system of record rather than as a log beside it.
Event Stream
An append-only, retained log of events that many independent consumers read at their own position, and can re-read.
Event Upcasting
Transforming an old event's stored form into the current shape as it is read, so historical events remain replayable after the schema changes.
Salesforce's Metadata-Driven Multi-Tenancy
Salesforce serves every customer from shared infrastructure with a single physical schema, storing customer-specific data structures as metadata rather than as separate tables.
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.
CI/CD
Merging work continuously into a shared trunk with automated verification, and keeping every commit in a state that could be released.
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 Group
A set of consumers that cooperatively read one stream, with each partition assigned to exactly one member, so the group collectively processes every message once.
Contract Testing
Verifying that a provider satisfies the expectations each of its consumers actually relies on, without running all the services together.
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.
Disaster Recovery
The plan and capability for restoring service after an event that takes out a whole site, region or system.
Golden Signals
The four measurements that cover most of what matters for a request-driven service: latency, traffic, errors and saturation.
GraphQL
A query language and runtime where the client specifies exactly which fields it needs, against a typed schema, usually via a single endpoint.
Idempotency Key
A client-generated unique value sent with a request so the server can recognise a retry and return the original result instead of acting twice.
Image Registry
The store from which container images are pulled, and an under-appreciated availability and security dependency of every deployment and every autoscale event.
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 design review presents a new event-driven platform. What cost questions do you ask before approving it?
What the interviewer is testing Whether cost is part of your architecture review or an afterthought handled by finance later, and whether you know the specific
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
Orders must trigger inventory reservation, a confirmation email, an analytics record and a fraud check. Queue, topic, or both — and what breaks if you choose wrong?
What the interviewer is testing Whether you know the difference between work distribution and notification — a distinction that produces one of the most confusi
A 43-second network partition caused GitHub over 24 hours of degraded service in 2018. How does a 43-second event become a day-long incident?
The case, as publicly reported On 21 October 2018, routine maintenance replacing failing optical equipment caused a 43 second loss of connectivity between GitHu
A team wants event sourcing for a new order service, citing audit requirements. What do you recommend?
The recommendation: probably an audit log, not event sourcing If the requirement is audit , event sourcing is a very expensive way to obtain it. An append only
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
When should a service call another synchronously, and when should it publish an event instead? Give me the deciding test, not a preference.
The deciding test Does this user action succeed or fail based on this callee's response? If yes, the call is synchronous, because you need the answer to decide.
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 streaming aggregation reports lower totals than the batch job it replaced. Both read the same source. What is likely happening?
The likely cause: late events dropped past the watermark The batch job reads a completed day and sees everything, including records that arrived hours after the
Consumer lag on a Kafka topic grows during peak and does not recover overnight. You add consumers and nothing improves. Why?
The mechanism Each partition is assigned to exactly one consumer within a group. With ten partitions and ten consumers, an eleventh consumer joins the group, is
Event-Driven Integration
Publishing facts rather than commands, and versioning event schemas.
Event-Driven Architecture
Publishing facts, and trading comprehensibility for decoupling.
Serverless vs Containers
Spiky and event-driven versus sustained throughput.
API & Integration
General material on integrating systems through contracts.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Enterprise Integration
Estate-wide integration strategy, standards and shared infrastructure.
Event Sourcing
Storing the change log as the system of record, and what that costs forever.
Event Sourcing
The event log as the system of record, with state as a projection.
Event Streaming
Retained ordered logs, consumer offsets, partitions and replay.
Integration Patterns
Routers, translators, splitters, aggregators and dead letter channels.
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.
Peak Event Readiness
Freeze, pre-scale, shed order, warm caches and rehearse.
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.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Chaos Engineering
Hypothesis-driven failure injection with a bounded blast radius.
Contract Testing
Verifying what consumers actually rely on, without a shared environment.
GraphQL
Client-specified queries, N+1 resolution and query-cost control.
Idempotency Keys
Client-generated keys stored atomically with the operation they guard.