Markdown: マークダウンのブロック引用構文とネスト

> This is a blockquote.
> This is the second line of the quote.

> This is a blockquote paragraph with > only on the first line.
This is the continuation (supported by some parsers).

> First paragraph.
>
> Second paragraph (with a blank line and `>` in between).

In *The Pragmatic Programmer*, the authors point out:

> The core of software development is not writing code, but managing complexity.
> A good programmer is not the one who writes the most code, but the one who makes code clearest.

> **Project Manager:** Can this feature go live this Friday?
>
> > **Developer:** The core functionality is ready, but some edge cases still need testing.
> >
> > > **QA Engineer:** I've run 80% of the test cases. Should have results by Wednesday.

> ## Core Argument of the Quoted Material
>
> This is the main body of the quoted content.
>
> ### Sub-Argument 1
>
> Detailed explanation of the sub-argument.

> Project Requirements:
>
> - Support 1,000 concurrent users
> - Response time < 200ms
> - 99.9% availability

> **Core Algorithm:**
>
> ```python
> def fibonacci(n):
>     if n <= 1:
>         return n
>     return fibonacci(n-1) + fibonacci(n-2)
> ```
>
> The above algorithm has O(2^n) time complexity and can be optimized with dynamic programming.

> ## Technical Design Review Results
>
> After team evaluation, we've decided to adopt a **microservice architecture**.
>
> | Approach | Scalability | Maintenance Cost |
> |:-----|:------:|:--------:|
> | Monolith | Low | Low |
> | Microservices | High | High |
>
> > Note: Microservices are suitable for teams of 10+. Small teams should start with a monolith.

> Standard blockquote: quoting an external author's viewpoint.

> **💡 Tip:** This is a tip callout—it emphasizes key information for the reader.

> **⚠️ Note:** This is a warning callout—it alerts readers to risks and helps them avoid pitfalls.

## Key Decision

We chose PostgreSQL as our primary database.

> **Decision Rationale:**
> 1. The team has 3 years of PostgreSQL experience
> 2. The project needs complex queries and transaction support
> 3. Tight budget—PostgreSQL is open-source and free

The original paper states:

> Experimental results show this method is effective.
>
> > Subsequent research further confirms:
> >
> > > After 10 independent replications, the results are consistent.

# Architecture Review Report

## Review Conclusion

Following the architecture review meeting on June 15, 2026, the team has made the following decisions:

## Database Selection

> **Final Decision:** Adopt PostgreSQL.
>
> **Rationale:**
> - The project requires complex geospatial queries (PostGIS)
> - The team has extensive PostgreSQL experience
> - Compared to MongoDB, PostgreSQL offers more robust transaction support
>
> | Comparison | PostgreSQL | MongoDB |
> |:-------|:----------:|:-------:|
> | Transactions | ✅ ACID | ✅ Multi-doc |
> | Geospatial | ✅ PostGIS | ✅ Built-in |
> | Team Experience | 3 years | 1 year |

## Deployment Plan

> **CEO's Opinion:**
>
> > I suggest starting with a monolith and splitting it once user numbers grow.
>
> **Engineering Team's Response:**
>
> We agree with this strategy. However, the database connection layer will be an independent module to facilitate future microservice migration.

## Reminders

> **⚠️ Note:** During migration, keep the old system running simultaneously for at least 2 weeks to ensure data integrity.