It's important that you understand that Azure SQL Database replicas are primarily used for read-scale out purposes and not for read/write scenarios. By design, the replicas are read-only to offload read-only query workloads and not intended for read/write access. This design supports scaling out read-heavy workloads without impacting the primary database's performance.
For read-write access, you might be looking at a failover scenario rather than a read replica. Azure SQL Database offers Failover Groups to automatically manage read-write and read-only access rules during failovers. In a failover group, the primary server is read-write, and the secondary server(s) in a different region can serve read-only traffic until a failover happens. After a failover, the roles are reversed.
Similar to Failover Groups but requires manual intervention for failovers. This feature is used for creating readable secondary replicas (up to four) in the same or different geographic location. The secondary databases are read-only until a failover is performed manually. After the failover, the secondary database becomes the primary and can accept read-write transactions.
For scenarios requiring both read and write capabilities across databases, consider using a sharding pattern. Sharding involves distributing data across multiple databases (shards) to spread out the load. Each shard can handle read-write operations, but this requires application logic to manage the distribution of data and queries across shards.