Practice vocabulary for raising architecture concerns in code review: data model changes, abstraction boundaries, service extraction, and PR architecture language.
0 / 14 completed
1 / 14
A reviewer writes: 'This changes the data model in a breaking way.' What concern is being raised?
A 'breaking data model change' means the change (e.g. renaming a column, changing a field type, removing a field) will break existing clients or data. The reviewer is flagging the need for a migration strategy, versioning, or backward compatibility.
2 / 14
A reviewer comments: 'The abstraction boundary isn't clear here.' What does this mean?
An unclear abstraction boundary means the code mixes concerns that should be separated — e.g. business logic bleeding into the data access layer, or presentation logic in a domain model. This leads to coupling and maintenance problems.
3 / 14
During code review, a senior engineer writes: 'I'd suggest moving this to a separate service.' What architecture concern does this reflect?
Suggesting service extraction in a review means the reviewer sees that the new functionality has different characteristics (scaling needs, team ownership, deployment frequency, or domain) that make it a candidate for microservice extraction.
4 / 14
What does a reviewer mean by 'this PR introduces a cross-cutting concern'?
Cross-cutting concerns (logging, security, error handling, caching) cut across multiple modules. A reviewer flagging this is suggesting the implementation should use a centralised pattern (middleware, aspect, decorator) rather than scattered ad-hoc implementations.
5 / 14
A reviewer says: 'This change has significant coupling implications.' What are they pointing out?
Coupling implications mean the change creates a dependency between components that now know too much about each other. High coupling makes refactoring risky and testing harder — the reviewer is asking for a more loosely coupled design.
6 / 14
Senior Developer: 'I'm seeing a potential scalability bottleneck here. We're handling all user authentication logic directly in this API endpoint. It feels like we'll quickly hit limits as our user base grows, and it makes future feature additions more complex.'
In the context of this code review comment, what architectural concern is Senior Developer primarily raising?
The comment highlights concerns about future growth and complexity. While documentation and security are important, Senior Developer is specifically focusing on the lack of scalability in handling authentication directly within the API endpoint – a common architectural bottleneck. This suggests they're worried about performance degradation and difficulty adding new features later due to tightly coupled logic. The other options represent secondary concerns that aren't the core issue being addressed.
7 / 14
Senior Developer: 'I'm seeing a potential scalability bottleneck here. We're handling all user authentication logic directly in this API endpoint. It feels like we'll quickly hit limits as our user base grows, and it makes future feature additions more complex.'
In the context of this code review comment, what architectural concern is Senior Developer primarily raising?
The comment highlights concerns about future growth and complexity. While documentation and security are important, Senior Developer is specifically focusing on the lack of scalability in handling authentication directly within the API endpoint – a common architectural bottleneck. This suggests they're worried about performance degradation and difficulty adding new features later due to tightly coupled logic. The other options represent secondary concerns that aren't the core issue being addressed.
8 / 14
Senior Developer: 'I'm seeing a potential scalability bottleneck here. We're handling all user authentication logic directly in this API endpoint. It feels like we'll quickly hit limits as our user base grows, and it makes future feature additions more complex.'
In the context of this code review comment, what architectural concern is Senior Developer primarily raising?
The comment highlights concerns about future growth and complexity. While documentation and security are important, Senior Developer is specifically focusing on the lack of scalability in handling authentication directly within the API endpoint – a common architectural bottleneck. This suggests they're worried about performance degradation and difficulty adding new features later due to tightly coupled logic. The other options represent secondary concerns that aren't the core issue being addressed.
9 / 14
Senior Developer: 'I'm seeing a potential scalability bottleneck here. We're handling all user authentication logic directly in this API endpoint. It feels like we'll quickly hit limits as our user base grows, and it makes future feature additions more complex.'
In the context of this code review comment, what architectural concern is Senior Developer primarily raising?
The comment highlights concerns about future growth and complexity. While documentation and security are important, Senior Developer is specifically focusing on the lack of scalability in handling authentication directly within the API endpoint – a common architectural bottleneck. This suggests they're worried about performance degradation and difficulty adding new features later due to tightly coupled logic. The other options represent secondary concerns that aren't the core issue being addressed.
10 / 14
Sarah from the frontend team writes in a code review comment: 'The component is tightly coupled to the API response format. Any change to the API will require a corresponding update here.' What architectural issue does Sarah highlight?
Sarah is pointing out 'high coupling,' meaning the frontend component is overly dependent on the API's specific details. This makes it difficult to change either side independently and increases the risk of introducing bugs when updates are made. The options presented – unit tests, JavaScript frameworks, or error handling – are unrelated to this core architectural concern.
11 / 14
David, the team lead, sends a Slack message during code review: 'This PR adds logging throughout the service, but it's not centralized. We have logs scattered across different modules.' What architectural concern is David raising?
David is concerned about the lack of centralized logging – this violates the DRY principle and can lead to inconsistent log formats. Scattered logs make it significantly harder to trace issues across the system efficiently, as debugging becomes far more complex and time-consuming. The other options—DRY, security, or synchronous logging—are less central to the immediate problem.
12 / 14
Maria writes in a PR description: 'This change introduces a global configuration object accessible from anywhere in the application. It simplifies some code but introduces potential for unintended side effects.' What architectural concern is Maria identifying?
Maria is highlighting the problem of introducing 'global state.' This means data exists outside of a specific component's control, making it difficult to reason about how changes will affect other parts of the system. It violates the Single Responsibility Principle and creates potential for unexpected behavior due to mutable global variables. Options A-D are related but not the core issue.
13 / 14
Kenji suggests during a standup update: 'We're using a single database connection pool for all microservices. It's simple to set up but could create bottlenecks if one service experiences heavy load.' What architectural consideration does Kenji bring to the discussion?
Kenji is concerned about 'resource contention.' Sharing a single connection pool across multiple microservices can lead to performance bottlenecks if one service monopolizes the connections. This negatively impacts the overall system's responsiveness and scalability. The other options address database design or monitoring, but not the core issue of shared resources.
14 / 14
Emily writes in a code review comment: 'This feature requires accessing data from three separate APIs. The logic to handle these API calls is tightly coupled within this module.' What architectural problem does Emily identify?
Emily is pointing out a lack of 'abstraction.' Tightly coupling multiple external API integrations within one module makes it difficult to change or update any of those APIs independently. This leads to increased complexity and maintenance overhead as changes ripple through the system. Options A-D are related concerns but don't capture the core issue of tight coupling.
What does the "Reviewing Architecture in Code Review Quiz" exercise practise?
Practice vocabulary for raising architecture concerns in code review: data model changes, abstraction boundaries, service extraction, and PR architecture language.
How many questions are in this exercise?
This exercise has 14 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Code Review Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Reviewing Architecture in Code Review Quiz" part of a larger series?
Yes — it's one exercise in the Code Review Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Code Review Language category page for related exercises, or browse the main Exercises hub for other IT English topics.