Software Architecture Consulting: What It Covers and When You Need It

By Viprasol Tech Team

---

Software architecture consulting addresses the decisions that are hardest to change later — data model design, service boundaries, technology choices, API contracts, and infrastructure topology. These decisions made early in a product's life persist for years and determine whether the system scales gracefully or requires expensive restructuring to accommodate growth.

Most architecture consulting engagements happen reactively — after the system has grown to the point where the original design can't support the next phase of growth. Proactive architecture review (before building) costs a fraction of reactive restructuring.

---

When Architecture Consulting Has the Highest Value

Before building a significant new system. Investing 2–4 weeks in architecture design before development saves months of rework. The architecture review identifies design errors when they're still cheap to fix.

Before a scaling milestone. "We're expecting 10x user growth over the next 12 months — what breaks?" A performance and scalability architecture review identifies bottlenecks before they become incidents.

After a significant incident. A post-incident architecture review identifies systemic weaknesses — not just the proximate cause of the incident, but the structural factors that allowed it to happen.

Before a major technical investment. Migrating to microservices, moving to a new cloud provider, adopting a new data platform — all benefit from independent architectural review before committing significant resources.

During technical due diligence (M&A or fundraising). Investors acquiring or funding a technology company need an independent assessment of technical quality, debt, and risk.

---

What an Architecture Review Covers

A comprehensive architecture review has five components:

1. Current State Documentation

Before evaluating the architecture, document it accurately. Many teams have incomplete or outdated architecture diagrams that don't reflect what's actually running in production.

Current state documentation:
- Service/component inventory (what exists, what it does)
- Data model (databases, schemas, data flows)
- Infrastructure topology (VPC, services, networking)
- Integration map (external APIs, third-party services)
- Deployment pipeline
- Monitoring coverage

The documentation itself often surfaces problems — integrations nobody knew existed, database tables with no clear owner, services with shared credentials.

2. Scalability Assessment

Where does the system fail as load increases? The analysis covers:

Database scalability: Connection pool sizing, query performance under load, index coverage, whether the schema design supports the access patterns at 10x scale.

Application scalability: Horizontal scaling capability, stateful components that can't scale horizontally, session management, cache invalidation.

Infrastructure scalability: Load balancer limits, auto-scaling configuration, NAT gateway throughput limits (a commonly missed bottleneck on AWS).

Common finding: The database is almost always the bottleneck. Applications scale horizontally easily; databases require more deliberate design.

-- Architecture review: identifying missing indexes
-- Run on production with pg_stat_user_tables and pg_stat_user_indexes
SELECT
  schemaname,
  tablename,
  seq_scan,          -- how many sequential scans (full table reads)
  idx_scan,          -- how many index scans
  n_live_tup,        -- approximate row count
  ROUND(seq_scan::numeric / NULLIF(seq_scan + idx_scan, 0) * 100, 1) AS seq_scan_pct
FROM pg_stat_user_tables
WHERE seq_scan > 100
  AND n_live_tup > 10000
ORDER BY seq_scan DESC;
-- High seq_scan_pct on large tables = missing index

3. Reliability and Resilience Analysis

Single points of failure, cascading failure modes, and recovery time:

• What happens if the database goes down?
• What happens if a third-party API is unavailable?
• What's the recovery time objective (RTO) and recovery point objective (RPO)?
• Are database backups being tested?
• Is there a runbook for common failures?

Architecture anti-patterns found in reviews:

// ANTI-PATTERN: synchronous call to external service in critical path
// If Stripe is slow, your entire checkout is slow
app.post('/checkout', async (req, res) => {
  const order = await createOrder(req.body);
  const payment = await stripe.charges.create({ ... });  // external call in critical path
  await fulfillOrder(order.id);
  res.json({ success: true });
});

// BETTER: decouple with async processing
app.post('/checkout', async (req, res) => {
  const order = await createOrder({ ...req.body, status: 'pending_payment' });
  await paymentQueue.add('process-payment', { orderId: order.id, ... });
  res.status(202).json({ orderId: order.id, status: 'processing' });
  // Client polls /orders/:id or gets webhook when payment completes
});

4. Security Architecture Review

Not a penetration test — a design-level security assessment:

• Authentication and authorization model
• Secret management (are credentials in environment variables? in code?)
• Data encryption at rest and in transit
• Input validation and output encoding
• Dependency vulnerability posture
• Audit logging coverage
• Network security (security groups, VPC configuration)

5. Prioritized Recommendations

The output is not a list of everything that could be better — it's a prioritized list of what to fix, in order of risk and effort:

Priority 1 (fix within 30 days — active risk):
  - Database connection pool is sized at 10; at current traffic, it will exhaust at 2x load
  - Admin API endpoints have no rate limiting — vulnerable to credential stuffing
  - Database backups exist but have never been tested for restoration

Priority 2 (address within 90 days — important):
  - No circuit breaker on payment provider integration — outage cascades to checkout
  - Missing indexes on orders table — seq scan at 50K rows, will degrade at 500K
  - JWT access tokens have 24-hour TTL — should be 15 minutes with refresh tokens

Priority 3 (strategic improvements):
  - Sessions stored in memory — can't scale horizontally without Redis session store
  - Monolithic deployment means any service failure requires full redeploy
  - No feature flag system — all deployments are big-bang releases

---

Common Architecture Patterns the Review Validates

Database per service (for microservices): Each service owns its data. Shared databases create tight coupling between services and make independent deployment impossible.

CQRS (Command Query Responsibility Segregation): Separate the write model (commands that change state) from the read model (queries for display). Solves the performance mismatch between complex writes and high-throughput reads.

Event sourcing (for audit requirements): Store events (what happened) rather than state (current value). Provides a complete audit trail and enables event replay for debugging or rebuilding derived state.

Saga pattern (for distributed transactions): When a business operation spans multiple services, coordinate it as a sequence of local transactions with compensating actions if any step fails — instead of a distributed transaction.

Strangler fig (for legacy modernization): Incrementally replace a legacy system by routing specific functionality to new services while the legacy system handles the rest. Avoids big-bang rewrites.

---

The Architecture Review vs. Code Review

An architecture review is not a code review — it operates at a higher level of abstraction.

Code quality matters, but even excellent code built on a flawed architecture will eventually fail to meet requirements. Architecture reviews address the structural decisions that determine the ceiling of what the code can achieve.

---

Engagement Structures and Costs

ADRs (Architecture Decision Records) are lightweight documents that capture each significant architectural decision: what was decided, what alternatives were considered, and why this choice was made. They're a deliverable that persists beyond the engagement.

---

Working With Viprasol

Our architecture consulting practice covers pre-development system design, existing system reviews, scalability assessments, and technical due diligence. We work across SaaS products, fintech platforms, trading systems, and data-intensive applications.

We deliver ADRs alongside recommendations, so decisions are documented for your team — not just in a consultant's report.

Our IT consulting services and cloud infrastructure practice both include architecture design as a primary service.

Need a software architecture review? Viprasol Tech provides system design and architecture consulting for startups and enterprises. Contact us.

---

See also: IT Consulting Services · Custom Software Development Cost · Microservices Development

Sources: Martin Fowler — Software Architecture Guide · AWS Well-Architected Framework · Michael Nygard — Release It! (O'Reilly)