5 exercises — master the vocabulary of enterprise low-code architecture: core vs edge, the strangler fig pattern, citizen-led governance models, architectural anti-patterns, and microservices orchestration.
0 / 19 completed
1 / 19
An enterprise architect presents a slide titled "Core vs Edge Architecture for Low-Code." They explain: "Low-code belongs at the edge — not at the core." What does this mean in enterprise architecture terms?
The core vs edge framework is the most important architectural principle guiding responsible enterprise low-code adoption — it prevents the most common and costly mistake: using low-code for systems that require enterprise-grade engineering.
Integration architecture:
Edge apps should never bypass the core — they must interact with core systems via officially published APIs (SAP OData, Salesforce REST API). Direct database connections from Power Apps to ERP databases are an anti-pattern that creates tight coupling and breaks when the core system upgrades.
Key vocabulary:
• System of record — the authoritative source of truth for a data entity (e.g. SAP is the system of record for purchase orders)
• System of engagement — an application layer that business users interact with, consuming data from systems of record
• Edge application — a departmental or process-specific app at the boundary of core systems; ideal for low-code
• Tight coupling — a dependency between two systems that breaks both when either changes; an architectural anti-pattern
2 / 19
A platform architect proposes: "We should use the strangler fig pattern to migrate our legacy monolith — starting with a low-code layer for the UI while the back-end is incrementally re-platformed." What is the strangler fig pattern?
The strangler fig pattern is a fundamental enterprise modernisation pattern described by Martin Fowler — understanding it is essential for architects discussing legacy system transformation at the intersection of low-code and traditional development.
How the strangler fig pattern works in a low-code context:
Phase
What happens
1. Facade
Build a routing layer (API gateway) in front of the legacy system; new requests can be intercepted and routed to new or old system
2. Parallel build
New low-code apps or microservices handle one bounded domain at a time (e.g. expense approval); legacy handles everything else
3. Traffic migration
Route the strangled function's traffic to the new system; validate in production with real users
4. Legacy atrophy
Each migrated function is turned off in the legacy system; legacy shrinks until it can be decommissioned
Why this is important for low-code architecture:
Low-code platforms are particularly well-suited to the strangler fig pattern because they can rapidly deliver edge applications (expense apps, approval workflows, reporting dashboards) that expose a modern UI while the legacy back-end continues to run — providing immediate user value without waiting for full re-platforming.
Key vocabulary:
• Strangler fig pattern — a modernisation approach replacing a legacy system incrementally by routing functionality to a new system one piece at a time; named after the strangler fig tree
• Big bang cutover — replacing an entire legacy system at once; higher risk alternative to the strangler fig approach
• Facade — an abstraction layer that hides the complexity of underlying systems; routes requests to legacy or new systems
• Bounded context — a domain boundary within which a particular model is consistent; the unit of decomposition in strangler fig migrations
3 / 19
An enterprise architect describes a governance model: "In our organisation, we use a citizen-led, IT-governed architecture. Business units build — but IT owns the runway." What does this model mean in practice?
The citizen-led, IT-governed model is the architectural operating model that distinguishes mature low-code enterprises from organisations where low-code has either stagnated (too much IT control) or created chaos (too little governance).
Responsibilities in the citizen-led, IT-governed model:
IT's "runway" responsibilities
Citizen developer's responsibilities
Environment strategy (DEV/TEST/PROD)
Identify the business problem to solve
Approved connector catalogue
Build the solution within the approved environment
DLP policies and security guardrails
Follow the training and governance requirements
CoE inventory and monitoring
Register solutions in the app catalogue
Training and certification programme
Own the solution lifecycle — including decommissioning
The "guardrail" metaphor:
IT builds the guardrails on the highway, not the traffic lights at every intersection. Guardrails (DLP policies, environment access control, security policies) prevent dangerous actions without requiring IT approval for every individual flow. Traffic lights (per-flow IT review) create the bottleneck that drives shadow IT.
Signs of model failure:
• Too much IT control → business teams give up on low-code, shadow IT using unapproved tools grows
• Too little governance → app sprawl, shadow IT proliferation, compliance incidents, unsupported critical flows
Key vocabulary:
• Citizen-led, IT-governed — business users build; IT controls the platform, security, and governance guardrails
• Guardrail — a governance control that prevents dangerous actions without blocking normal operations
• Runway — the platform infrastructure, policies, and enablement that IT provides for citizen developers to build on
• Operating model — the organisational structure and process framework governing how work gets done
4 / 19
During an architecture review, the panel shows a scenario and asks: "Should we use low-code here, or is this a case where we should not use it?" The scenario: a global financial services firm needs a real-time trading signal aggregation engine processing 50,000 events per second with sub-5ms latency. What is the correct answer?
Knowing when NOT to use low-code is as important as knowing when to use it — and being able to argue this clearly with specific technical reasoning is a mark of architectural maturity.
Why low-code fails this scenario:
Requirement
Low-code reality
Required architecture
50,000 events/second
Power Automate: ~100-500 cloud flow executions/min per tenant
Apache Kafka / Azure Event Hubs (millions/sec)
Sub-5ms latency
Power Automate: typically 1–5 seconds per run
In-process C++ / Rust / FPGA
Stateful stream aggregation
No native stream processing; stateless per run
Apache Flink / Azure Stream Analytics
Architectural anti-patterns this question targets:
• Using a business process automation tool for stream processing
• Confusing functional correctness ("it does the right calculation") with non-functional correctness ("it runs fast enough under load")
• Selecting a platform based on organisational familiarity rather than technical fitness
The right question to ask:
"What are the non-functional requirements (throughput, latency, availability, data volume) and do they fall within the platform's published operating envelope?"
Appropriate low-code use cases in financial services:
• Compliance exception approval workflows
• Regulatory reporting data collection forms
• Internal expense reimbursement and budget approval flows
• Client onboarding document collection apps
Key vocabulary:
• Non-functional requirement (NFR) — a quality attribute requirement (latency, throughput, availability) as opposed to a functional requirement (what the system does)
• Throughput — the number of operations processed per unit of time (events per second, transactions per minute)
• Latency — the time between a request being made and a response being received
• Stream processing — real-time processing of continuous data streams; requires purpose-built infrastructure
5 / 19
A solutions architect proposes: "For the new microservices platform, we want citizen developers to build orchestration flows in Power Automate that call individual microservices — effectively using Power Automate as the orchestration layer above the microservices mesh." Is this a sound architectural pattern?
Using Power Automate as a business process orchestration layer above microservices is a genuinely sound architectural pattern — it is deployed in production by large enterprises and reflects a mature understanding of the complementary strengths of each architectural layer.
Why this pattern works:
Layer
Responsibility
Changed by
Power Automate (orchestration)
When to call services; routing; approvals; notifications
Business / CoE team; no sprint needed
API Gateway
Auth, rate limiting, routing, versioning
Platform / API team
Microservices
Domain logic, data management, computation
Engineering team; full SDLC
Key design requirements for this pattern to succeed:
• Microservices must expose stable, versioned REST APIs with clear contracts (OpenAPI spec)
• Each microservice must be idempotent for POST/PUT operations (safe to call twice)
• Error handling must be implemented at the Power Automate layer for failed microservice calls
• Custom connectors must be pre-built and maintained by the platform team — not improvised by citizen developers directly
• The CoE DLP policy must approve the API connector used to call microservices
Anti-pattern to avoid:
Citizen developers calling microservice APIs directly with the "HTTP" connector without a governance-approved custom connector — this bypasses auth standards, rate limiting, and monitoring.
Key vocabulary:
• Orchestration layer — the layer responsible for coordinating the execution sequence of multiple services in a business process
• Choreography vs orchestration — in choreography, services react to events and coordinate themselves; in orchestration, a central controller (Power Automate) directs each step
• API contract — the agreed-upon specification of what an API accepts, returns, and guarantees; specified by OpenAPI definition
• Stable API — a versioned API that does not introduce breaking changes; essential for low-code consumer confidence
6 / 19
Liam (Senior Developer) comments on a PR draft: 'This flow is incredibly complex. We're building custom UI components *within* the low-code platform to handle data transformations – it feels like we're fighting against the platform's capabilities. Shouldn't we be leveraging pre-built connectors and integrations instead?' What does Liam likely mean by this critique?
Liam's comment highlights a key challenge with excessive customization in low-code. The core issue isn't the platform itself, but rather extending it beyond its intended design by creating bespoke components – this creates dependency and makes future upgrades harder. Using pre-built connectors is generally *more* aligned with the low-code philosophy of leveraging existing tools.
7 / 19
Sarah (Product Owner) sends a Slack message: 'Just got this API response from the Data Team – they're saying the low-code app is generating excessive database queries. They've identified that our UI layer is repeatedly hitting the same data tables to retrieve small sets of information. This is impacting performance significantly.' What architectural concern does Sarah raise?
Sarah's message points to a common issue with low-code: often, developers bypass best practices and create inefficient data access patterns. Repeated queries against the same tables, even for small sets of data, can quickly degrade performance – this is where optimization of application logic is crucial.
8 / 19
Mark (Enterprise Architect) describes a new project: 'We're building a customer onboarding flow. It's critical that users can quickly and easily complete the process – ideally within 5 minutes. We need to minimize development time, but also maintain a good user experience.' Considering this scenario, what is the *most* appropriate architectural approach for this project using low-code?
For rapid onboarding flows where speed is paramount, leveraging pre-built templates and quickly adapting them is the most effective strategy. This allows developers to focus on business logic rather than spending time building core functionality from scratch. A hybrid approach can be useful but introducing significant custom code risks increasing complexity.
9 / 19
Liam (Senior Developer) comments on a PR draft: 'This flow is incredibly complex. We're building custom UI components *within* the low-code platform to handle data transformations – it feels like we're fighting against the platform's capabilities. Shouldn't we be leveraging pre-built connectors and integrations instead?' What does Liam likely mean by this critique?
Liam's comment highlights a key challenge with excessive customization in low-code. The core issue isn't the platform itself, but rather extending it beyond its intended design by creating bespoke components – this creates dependency and makes future upgrades harder. Using pre-built connectors is generally *more* aligned with the low-code philosophy of leveraging existing tools.
10 / 19
Sarah (Product Owner) sends a Slack message: 'Just got this API response from the Data Team – they're saying the low-code app is generating excessive database queries. They've identified that our UI layer is repeatedly hitting the same data tables to retrieve small sets of information. This is impacting performance significantly.' What architectural concern does Sarah raise?
Sarah's message points to a common issue with low-code: often, developers bypass best practices and create inefficient data access patterns. Repeated queries against the same tables, even for small sets of data, can quickly degrade performance – this is where optimization of application logic is crucial.
11 / 19
Mark (Enterprise Architect) describes a new project: 'We're building a customer onboarding flow. It's critical that users can quickly and easily complete the process – ideally within 5 minutes. We need to minimize development time, but also maintain a good user experience.' Considering this scenario, what is the *most* appropriate architectural approach for this project using low-code?
For rapid onboarding flows where speed is paramount, leveraging pre-built templates and quickly adapting them is the most effective strategy. This allows developers to focus on business logic rather than spending time building core functionality from scratch. A hybrid approach can be useful but introducing significant custom code risks increasing complexity.
12 / 19
Liam (Senior Developer) comments on a PR draft: 'This flow is incredibly complex. We're building custom UI components *within* the low-code platform to handle data transformations – it feels like we're fighting against the platform's capabilities. Shouldn't we be leveraging pre-built connectors and integrations instead?' What does Liam likely mean by this critique?
Liam's comment highlights a key challenge with excessive customization in low-code. The core issue isn't the platform itself, but rather extending it beyond its intended design by creating bespoke components – this creates dependency and makes future upgrades harder. Using pre-built connectors is generally *more* aligned with the low-code philosophy of leveraging existing tools.
13 / 19
Sarah (Product Owner) sends a Slack message: 'Just got this API response from the Data Team – they're saying the low-code app is generating excessive database queries. They've identified that our UI layer is repeatedly hitting the same data tables to retrieve small sets of information. This is impacting performance significantly.' What architectural concern does Sarah raise?
Sarah's message points to a common issue with low-code: often, developers bypass best practices and create inefficient data access patterns. Repeated queries against the same tables, even for small sets of data, can quickly degrade performance – this is where optimization of application logic is crucial.
14 / 19
Mark (Enterprise Architect) describes a new project: 'We're building a customer onboarding flow. It's critical that users can quickly and easily complete the process – ideally within 5 minutes. We need to minimize development time, but also maintain a good user experience.' Considering this scenario, what is the *most* appropriate architectural approach for this project using low-code?
For rapid onboarding flows where speed is paramount, leveraging pre-built templates and quickly adapting them is the most effective strategy. This allows developers to focus on business logic rather than spending time building core functionality from scratch. A hybrid approach can be useful but introducing significant custom code risks increasing complexity.
15 / 19
During a sprint planning meeting, the Product Owner says, 'Let's leverage low-code to rapidly prototype this new customer journey. We can use a no-code platform for the initial user flows and then integrate with our existing backend services.' What is the primary benefit of this approach according to the Product Owner?
The Product Owner's statement emphasizes rapid prototyping and experimentation. Low-code & no-code tools are designed to accelerate this process by allowing quick iterations without extensive coding. The other options represent potential drawbacks – a lack of experience can hinder success, prioritizing speed over maintainability is risky, and complete elimination of traditional coding isn't realistic.
16 / 19
Senior Developer Anya comments on a PR draft: 'I'm seeing a lot of data transformation logic being handled within the low-code canvas. While it's fast to build initially, this creates tight coupling and makes future refactoring incredibly difficult. We need to consider exporting these transformations as reusable components.' What is Anya primarily concerned about in this situation?
Anya is highlighting the issue of 'tight coupling,' a common problem when excessive logic is embedded within a low-code environment. This makes future changes and maintenance significantly harder. The PR's focus on immediate development over long-term maintainability introduces technical debt – a key concern for experienced developers.
17 / 19
Developer Ben sends this Slack message to the team: 'The data team just flagged some serious performance issues with the low-code app. They're seeing a massive spike in database queries when users are filtering by multiple criteria. It looks like our UI layer is repeatedly hitting the same API endpoint without proper caching.' What is the *root cause* of the problem, as suggested by Ben?
Ben's message clearly points to inefficiency in the UI layer's query design. The repeated hits to the same API endpoint without caching are causing excessive database load—this is a common performance issue when low-code apps lack robust data access patterns. It's not about the platform itself, nor the database schema or bandwidth.
18 / 19
You're writing a PR description for a new feature: 'This change implements a drag-and-drop interface within the low-code platform to allow users to create custom reports. The UI component handles data mapping and formatting on the fly, providing a streamlined experience. We've focused on usability and rapid iteration.' What is the *primary goal* of this PR update?
The description explicitly states the aim is to 'empower non-technical users,' highlighting the core benefit of low-code – ease of use and self-service. While performance and complexity reduction are potential outcomes, the primary goal is centered on user enablement.
19 / 19
During a daily standup meeting, Mark (Lead Developer) says: 'Yesterday, I spent most of my time troubleshooting performance issues in our low-code app. We're seeing significant latency when processing large datasets – it's likely due to inefficient data transformations within the UI layer.' What is Mark *primarily* reporting on today?
Mark explicitly states he was 'investigating performance issues.' This is the core focus of his update – reporting on a technical challenge and its potential cause. The other options represent different types of updates that wouldn't fit this scenario.
What will I practise in "Low-Code Architecture Language — Low-Code & No-Code Exercises"?
Practice English vocabulary for low-code enterprise architecture: core vs edge, strangler fig pattern, citizen-led IT-governed model, when not to use low-code, microservices orchestration. 5 exercises.
How many exercises are in this module?
This module has 19 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Low-Code & No-Code exercises?
Browse the full Low-Code & No-Code hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.